We are working on a new feature in our API with the Data Source Endpoint Separation functionality. This enhancement allows applications to obtain data from each source individually, optimizing the efficiency, scalability, and security of the system.
Until now, developers accessed all data sources configured for a user through a single endpoint. With this update, each request can be directed to a specific source, such as Dexcom, Fitbit, Garmin, Oura, Polar, Whoop, or Withings, improving performance and reducing unnecessary data overhead.
Key improvements of the new endpoint:
- More specific access: Data can be requested from a specific source instead of receiving all sources in a single response.
- Increased efficiency: Faster responses with a lower estimated response time under normal conditions.
- Improved scalability: Optimization in the handling of multiple concurrent requests.
- Enhanced security: Credential validation in each request with authentication using secure tokens.
Impact on developers and users
This update gives developers more precise control over data applications, making it easier to integrate with applications that require wearable-specific information.
Endpoint Structure
For the current authorizer endpoint:
/api/v1/user_id/<user_id>/data_source/<data_source>/authorizer
Which will be answered as follows:
{
"data_source": "Fitbit",
"authorized": false,
"authorization_url": "https://www.fitbit.com/oauth2/authorize?response_type"
}
For more information, please see our API Reference.
Frequently Asked Questions:
1. What is the Data Source Separation in the Authorization Endpoint?
This is an improvement to our API that allows requesting authorization data for a specific source (such as Fitbit, Garmin, or Oura) instead of retrieving information for all sources at once. This enhances system efficiency, security, and scalability.
2. What is the main benefit of this change?
Previously, developers received information from all sources in a single request, which could generate unnecessary data and slow down responses. With this improvement, only the needed source data is retrieved, optimizing performance and security.
3. How does this change affect developers?
It gives them greater control over data integration in their applications. Now, they can request specific information from each wearable or health platform, improving system efficiency.
4. What is the structure of the new endpoint?
The new endpoint format is:
/api/v1/user_id/<user_id>/data_source/<data_source>/authorizer
For example, to retrieve authorization data from Fitbit, the request would be:
/api/v1/user_id/abc123/data_source/Fitbit/authorizer
5. What does the new endpoint response look like?
A successful request will return a JSON with the requested source’s information. Example response for Fitbit:
{
"data_source": "Fitbit",
"authorized": false,
"authorization_url": "https://www.fitbit.com/oauth2/authorize?response_type"
}
6. What data sources are supported by this new endpoint?
The supported data sources include:
- Fitbit
- Garmin
- Oura
- Withings
- Polar
- Whoop
- Dexcom
7. Is it mandatory to upgrade to the new endpoint version?
Not immediately, but it is recommended to take advantage of the efficiency and security benefits. The previous version will remain available for a limited time.
8. Does this change impact user authentication?
No, authentication still works with secure tokens, but now each request will validate credentials more specifically for each data source.
9. How does this change improve system scalability?
The new approach allows handling multiple concurrent requests more efficiently, reducing server load and improving response times.
10. What happens if I request a data source that is not supported?
If an unrecognized data source is requested, the system will return an error indicating that the source is invalid.
11. Where can I find more information about the Endpoint?
You can check our API reference documentation for more details on how to integrate this new endpoint into your applications.