Our smart products and apps are all about greater freedom and more choice. And that goes for developers, too.
The Withings API allows developers to create new applications that take advantage of the Withings devices and the data they record.
Using the Withings API, developers can access health data measured by our products, including weight, body fat, lean mass, blood pressure and heart rate and use it to improve their existing user experience – or to create brand new ones. The API is based on OAuth for authentication. It is free to use and lets you retrieve data from our devices seamlessly and without hold-ups.
Simply register your application to get going.
Check out the documentation for more details and sample code. If you have any questions, please contact us at contact-mkt@withings.com.
The Withings Body metrics Services API (further referred as the WBS API) is a set of webservices that gives developers and third-party applications a limited access to the Withings database and user data.
Any access to data through the WBS API is conditioned by the user’s explicit prior approval. The authentication and approval procedure uses OAuth and is described in details in our Oauth implementation guide.
The WBS API offers a notification system that sends Push notifications in near-real time whenever new data is recorded for a user who linked their account with your service. We strongly encourage all partners to make the most of this notification system in order to create the best user experience and spread out server charge.
All body metrics data types measured by Withings devices are available through the WBS API, in addition to other relevant user data. An exhaustive list of all data types available can be found in the present documentation, under the Service Catalogue section.
The WBS API is currently licensed for free. We invite you to review the Terms & Conditions page for more information before registering your service, website, application, etc. here. Do not hesitate to contact us if you have any question regarding this process under the category “Business inquiries → Partnership and API”.
We have developed sample code for various programming languages, please find them below.
You'll find a sample php code with small explanation here. It's using a lightweight Oauth library you can modify to get a full functionnal oauth client. You just have to follow the code in example.php file.
An account is what Withings users use to log into their dashboard. An account is uniquely defined by an email address and a password, entered by the end user when registering. A single account may contain several users (e.g.: members of a family).
The WBS API connects third-party service with a user, but uses the account’s e-mail and password for authentication. An account must have at least one user in it in order to make the connection through the WBS API possible.
A user of a Withings device is uniquely defined by a userid and is tied to your application through their Oauth credentials. These parameters are mandatory in all requests and are given to your application as soon as you tie your application to the userid. For more information on setting up and retrieving Oauth credentials between your application and a Withings user, please refer to Oauth implementation guidelines. Every single request made to WBSAPI must include authentication parameters, and in particular an Oauth signature that will allow the API to authenticate you.
The required Oauth parameters are:
oauth_consumer_key: the Oauth token tied to your very own application. Could be thought as a public key for your application. This token is retrieved during the Oauth provisionning setup between the user and your application, refer to Oauth implementation guidelines to get your application's credentials.
Eg: oauth_consumer_key=7e563166232c6824642b4c277350494ff55f392b353e5d49712a34762a
oauth_token: The Oauth token of the Withings user tied to your application (ie tied to your own consumer_token). This token is retrieved during the Oauth provisionning setup between the user and your application, refer to Oauth implementation guidelines.
Eg: oauth_token=c68567f1760552958d713e92088db9f5c5189754dfe4e92068971f4e25d64
oauth_nonce: a random hexadecimal string you generate.
Eg: oauth_nonce=f22d74f2209ddf0c6558a47c02841fb1
oauth_version: the supported Oauth version, currently 1.0.
Eg : oauth_version=1.0
oauth_signature_method: the Oauth signature method, preferred method is HMAC-SHA1.
Eg : oauth_signature_method=HMAC-SHA1
oauth_timestamp: the current EPOCH timestamp.
Eg: oauth_timestamp=1309783586
oauth_signature: the Oauth signature. This is calculated from the complete HTTP request. Please see Signing an Oauth request for complete guide on signing your requests to the WBSAPI.
Eg: oauth_signature=yAF9SgZa09SPl3H1Y5aAoXgyauc
A complete WBSAPI request would be:
http://wbsapi.withings.net/measure?action=getmeas&oauth_consumer_key=7e563166232c6821742b4c277350494a455f392b353e5d49712a34762a&oauth_nonce=f22d74f2209ddf0c6558a47c02841fb1&oauth_signature=yAF9SgZa09SPl3H1Y5aAoXgyauc=&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1309783586&oauth_token=c68567f1760552958d713e92088db9f5c5189754dfe4e92068971f4e25d64&oauth_version=1.0&userid=1229
You can test your request here
Although the HTTP standards states that the HTTP request parameters order do not matters, they actually do when it comes to OAuth authentication.
So that to allow for non ambiguous signature generation, and since signature is derived from the request, the Oauth standard clearly states that the signature must be calculated on a "base string" obtained from the parameters contained in the request (except the oauth_signature of course) you want to submit, and that all the parameters of the query shall be sorted alphabetically. Hence, signing "userid=12&oauth_method=HMAC-SHA1..." and signing "oauth_method=HMAC-SHA1&userid=12..." will result in two different signatures and hence your authentication will fail.
Please make intensive use of Quonos Oauth Checker to check your authentication algorithms.
Please check the dedicated page for Oauth authentication guidelines
The WBS API is REST-based. Basically, WBS requests are sent as HTTP POST or GET requests.
A typical WBS API service request follows this template :
http://wbsapi.withings.net/[service_name]?action=[action_name]&[parameters]
where:
[service_name] is the requested service,
[action_name] is the action you want to perform on the requested service,
[parameters] are parameters, mandatory or optional, passed to the requested service.
Alongside the [parameters] aforementioned, you will need to provide the required Oauth related parameters. These are not detailled here for simplicity's sake, but please keep in mind that Oauth authentication is mandatory. More information regarding Oauth are given in the Oauth section. Please make sure you first carefully read our Oauth implementation guideline beforehand.
Every service needs a mandatory action parameter. For example, the user service has two possible actions (getbyuserid and update). action is a parameter of the GET or POST request (user?action=getbyuserid)
For every thing you want to do, there is a service and an action. The measure?action=getmeas service, which gets anything ranging from the user's weight and body fat to blood pressure and heart pulse, is probably the most useful.
Responses to such requests are JSON documents. All responses look like the following:
{"status":0, "body":{} }
The body field may eventually be absent or empty, depending on the service/action requested and the success or failure of the requested action.
Any single response will provide a mandatory status field. A status value set to 0 means that the action was successfully processed. Other values mean the request was not processed properly.
Here the responses codes with their description :
| Code | Description |
|---|---|
| 0 | Operation was successful |
| 247 | The userid provided is absent, or incorrect |
| 250 | The provided userid and/or Oauth credentials do not match. |
| 286 | No such subscription was found |
| 293 | The callback URL is either absent or incorrect |
| 294 | No such subscription could be deleted |
| 304 | The comment is either absent or incorrect |
| 305 | Too many notifications are already set |
| 342 | The signature (using Oauth) is invalid. |
| 2555 | An unknown error occurred |
A json library IS available for your programming language at http://www.json.org. Please don't try to parse a JSON document without first visiting this site. Use an already available JSON library: it saves a lot of effort.
As a first example (and this is a good starting point to check that this is working in your actual environement):
http://wbsapi.withings.net/once?action=probe
returns
{"status":0}
This service will return an array containing information regarding the specified user.
This can be used to retrieve a user's firstname, lastname, gender, or birthdate.
Issuing such a request on a professional account 'unknown' user will only yield id and firstname elements since other ones are not significant for anonymous users.
| Required | Name | Type | Description |
|---|---|---|---|
| Required | userid | integer | The userid of the target user. This can be obtained through an account/getuserslist or through the user's "Share" overlay in the dashboard. |
| Name | Type | Description |
|---|---|---|
| id | integer | The user identifier |
| firstname | UTF-8 encoded string | The user's firstname |
| lastname | UTF-8 encoded string | The user's lastname |
| shortname | UTF-8 encoded string | The user's shortname |
| gender | boolean | The user's gender (0 for male, 1 for female) |
| fatmethod | integer | Byte indicating the Body Composition Formula in use |
| birthdate | integer (EPOCH format) | The user's birthdate |
In the following example, public information about the user are requested:
http://wbsapi.withings.net/user?action=getbyuserid&userid=29
Here is what is returns:
{
"status": 0,
"body": {
"users": [
{
"id": 29,
"firstname": "John",
"lastname": "Doe",
"shortname": "JON",
"gender": 0,
"fatmethod": 0,
"birthdate": 211629600,
}
]
}
}
Several use cases can be performed with this service, depending on its input parameters.
The userid parameter is mandatory. ALL others are provided for filtering purposes and are optional.
| Required | Name | Type | Description |
|---|---|---|---|
| Required | userid | integer | The userid of the target user. This value is obtained when your user links his/her Withings account with your application. |
| optional | startdate | integer (EPOCH format) | Will prevent retrieval of values dated prior to the supplied parameter. |
| enddate | integer (EPOCH format) | Will prevent retrieval of values dated after the supplied parameter. | |
| devtype | integer | Will retrieve data for this particular device type. For example, using &devtype=1 will retrieve all body scale related measures (including weight, fatmass and fatfree mass), while using &devtype=0 will retrieve all user personal data (ie. the height and weight entered at user creation time). Can be used as a bitmask if necessary. | |
| meastype | integer | Will restrict the type of data retrieved (see below the type list). Please note that currently this filter only supports weight (ie type 1) and height (ie type 4) types. | |
| lastupdate | integer (EPOCH format) | (EPOCH format) Is useful for performing data synchronization. It can be used by the system using the WBS API to supply the last time (EPOCH format) it acquired data. Only entries which have been added or modified since this time are retrieved. | |
| category | integer | Can be set to 2 to retrieve objectives or to 1 to retrieve actual measurements. | |
| limit | integer | Can be used to limit the number of measure groups returned in the result. For instance, setting &limit=1 will return the last measure group only. Measure groups are always delivered from the newest to the oldest one | |
| offset | integer | Can be used to skip the 'offset' most recent measure group records of the result set. For instance, setting &offset=10 will return the 11th measure group and onward. Used in conjunction with limit, it can be used to acquire large data sets in several requests. |
As with every service, the answer starts with a status that should be 0, and a body that contains the actual result, an array of measuregrps (measure groups) related to the specified user.
Each measure group contains the following attributes:
| Measure group content fields | ||
| Name | Type | Description |
|---|---|---|
| grpid | integer | A unique grpid (Group Id), useful for performing synchronization tasks. |
| attrib | integer | An attrib (Attribute), defining the way the measure was attributed to the user. It may take the values shown in the Attribution status table below. |
| date | integer (EPOCH format) | The date at which the measure was taken or entered. |
| category | integer | The category of the group. A measure group can represent either measures captured by the device or objectives set by the user. The category field indicates for each measure group whether the measures in the group are measurements or targets. Refer to the Category values table below. |
| measures | array | An array of measures that belong to this particular measure group. |
A measure is an actual measurement of something. It has three parameters:
| Measure content fields | |
| Name | Description |
|---|---|
| type | A type which can be one of the ones specified in the Measure types table. |
| value | A value which is the actual value of the measure (integer). |
| unit | A unit which represents the power of 10 that has to be multiplied by value to find the actual data (integer). |
| Attribution status table | |
| Attribution Mode | Description |
|---|---|
| 0 | The measuregroup has been captured by a device and is known to belong to this user (and is not ambiguous) |
| 1 | The measuregroup has been captured by a device but may belong to other users as well as this one (it is ambiguous) |
| 2 | The measuregroup has been entered manually for this particular user |
| 4 | The measuregroup has been entered manually during user creation (and may not be accurate) |
| Category table | |
| Category | Description |
|---|---|
| 1 | Measure |
| 2 | Target |
| Measure types table | |
| Type | Description |
|---|---|
| 1 | Weight (kg) |
| 4 | Height (meter) |
| 5 | Fat Free Mass (kg) |
| 6 | Fat Ration (%) |
| 8 | Fat Mass Weight (kg) |
| 9 | Diastolic Blood Pressure (mmHg) |
| 10 | Systolic Blood Pressure (mmHg) |
| 11 | Heart Pulse (bpm) |
| Device types table | |
| Type | Description |
|---|---|
| 0 | User related (for the moment, only height and weight) |
| 1 | Body scale |
| 4 | Blood pressure monitor |
The actual measure value has to be computed from the value field using this formula:
real_value = value * 10^unit
As an example, the following JSON measure { "value": 79300, "unit": -3, "type": 1 } means "This is a weight measurement of 79,3 kg".
Note: Our units are SI units (kilogram, meter, mmHg, etc.). In case you come from a country that uses the imperial system (ie, Burma, Liberia, or the United States), you may have to convert the values to your local representation.
| Name | Description |
|---|---|
| updatetime | The webservices local timestamp at which the Json response was generated |
| more | If present, this field means that your query yielded too many measure groups to fit in a single response. Either you provided a limit parameter and the query yielded more groups than limit, or you didn't and the query yielded more than the default implicit limit (currently 2048 groups by query). In any case, it is up to your application to request remaining groups using measure/getmeas and providing offset parameter. The more value represents the number of remaining groups still to be fetched. |
| measuregrps | An array containing the measures, see above |
http://wbsapi.withings.net/measure?action=getmeas&userid=29&startdate=1222819200&enddate=1223190167
{
"status": 0,
"body": {
"updatetime": 1249409679,
"measuregrps": [
{
"grpid": 2909,
"attrib": 0,
"date": 1222930968,
"category": 1,
"measures": [
{
"value": 79300,
"type": 1,
"unit": -3
},
{
"value": 652,
"type": 5,
"unit": -1
},
{
"value": 178,
"type": 6,
"unit": -1
},
{
"value": 14125,
"type": 8,
"unit": -3
}
]
},
{
"grpid": 2908,
"attrib": 0,
"date": 1222930968,
"category": 1,
"measures": [
{
"value": 173,
"type": 4,
"unit": -2
}
]
}
]
}
}
The most effective way for third parties to retrieve measurements updates is to setup Push notifications for the users who have linked their account with them. Notifications are handled on a user-per-user basis: each third party application need to subscribe once for every user being monitored, as explained here. Each time the subscribed users use their Withings device to take a new measurement, or manually add or modify any measurement or objective, the WBS API will send notifications to all their monitoring third parties.
Please note that a given user cannot be subscribed by more than 16 third party services.
When the WBS API sees that subscriber data has been modified, it sends a notification to the subscribing third party application. The notification contains information that helps to determine what should be downloaded to remain in sync.
Would you need to list all the subscriptions you previously set for a given user, have a try with list.
The subscription can be revoked at anytime, as explained here.
This service allows third parties to subscribe to notifications. Once the notification service has been subscribed, the WBS API will notify the subscriber whenever the target user's measurements or objectives are added, modified or deleted.
This allows third party applications to remain in sync with user's data.
To monitor a user, its userid is needed.
Two parameters are mandatory in all cases : userid and callbackurl. The optional parameter appli can be used to restrict the request to the given device type.
| Required | Name | Type | Description |
|---|---|---|---|
| Required | userid | integer | The userid of the target user. This can be obtained through an account/getuserslist or through the user's "Share" overlay in the dashboard. |
| required | callbackurl | URL-encoded string | The URL the API notification service will call WBS API notification are merely HTTP POST requests to this URL (such as http://www.yourdomain.net/yourCustomApplication.php ?userid=123456&startdate=1260350649 &enddate=1260350650). Those requests contain startdate and enddate parameters (both are integers in EPOCH format) and the userid it refers to. It is up to the targeted system to issue a measure/getmeas request using both figures to retrieve updated data. This URL shall be provided as a URL-encoded string. Please refer to w3schools URL encoding reference to learn more about URL encoding, use free online URL encoders or check the example provided. The URL length shall not be greater than 128 characters. |
| required | comment | UTF-8 encoded string | The comment string is used as a description displayed to the user when presenting him your notification setup. |
| optional | appli | integer | Default value : 1 (Bodyscale). This field specifies the device type for which the notification is to be activated. See measure/getmeas for supported device types. |
This service has no other answer than the status code that should be zero upon completion.
In this example, we assume the target callback URL is http://www.yourdomain.net/yourCustomApplication.php. Once URL-encoded (you can find free online URL encoders here, this transforms into the following :
http%3a%2f%2fwww.yourdomain.net%2fyourCustomApplication.php
As a consequence, the resulting subscribe request results in the following. Please note how the URL-encoded form of the callback URL was used, not the callback URL itself :
http://wbsapi.withings.net/notify?action=subscribe&userid=29&callbackurl=http%3a%2f%2fwww.yourdomain.net%2fyourCustomApplication.php&comment=Your%20Own%20Application%20Description
{
"status": 0
}
This service allows third party applications to check whether the notification service was previously subscribed on a specific user and to retrieve the subscription expiry date.
Two parameters are mandatory in all cases : userid and callbackurl. The optional parameter appli can be used to restrict the request to the given device type.
| Required | Name | Type | Description |
|---|---|---|---|
| Required | userid | integer | The userid of the target user. |
| required | callbackurl | URL-encoded string | The URL-encoded URL used when subscribing to the notification service for the specified user. |
| optional | appli | integer | Default value : 1 (Bodyscale). This field specifies the device type for which the notification is to be retrieved. See measure/getmeas for supported device types. |
As with every service, the answer starts with a status that should be 0, and a body that contains the actual result, in this case the expiry date of the notification subscription for this user and its associated comment.
http://wbsapi.withings.net/notify?action=get&userid=29&callbackurl=http%3a%2f%2fwww.yourdomain.net%2fyourCustomApplication.php
{
"status": 0,
"body": {
"expires": 2147483647,
"comment": "Your Own Application Description"
}
}
This service allows third party applications to list all their currently provisionned notification callbacks for a specific user and to retrieve the subscriptions expiry dates.
Only the userid parameter is mandatory. The optional parameter appli can be used to restrict the request to the given device type.
| Required | Name | Type | Description |
|---|---|---|---|
| Required | userid | integer | The userid of the target user. |
| optional | appli | integer | Default value : 1 (Bodyscale). This field specifies the device type for which the notification is to be retrieved. See measure/getmeas for supported device types. |
As with every service, the answer starts with a status that should be 0, and a body that contains the actual result, in this case the expiry date of the notification subscription for this user and its associated comment.
http://wbsapi.withings.net/notify?action=list&userid=1229
{
"status":0,
"body": {
"profiles": [
{"expires":2147483647,"comment":"http:\/\/www.withings.com"},
{"expires":2147483647,"comment":"http:\/\/www.corp.withings.com"}
]
}
}
This service allows third party applications to revoke a previously subscribed notification.
This will disable the notification feature between the WBS API and the specified applications for the specified user.
Two parameters are mandatory in all cases : userid and callbackurl. The optional parameter appli can be used to restrict the request to the given device type.
| Required | Name | Type | Description |
|---|---|---|---|
| Required | userid | integer | The userid of the target user. |
| required | callbackurl | URL-encoded string | The URL-encoded URL used when subscribing to the notification service for the specified user. |
| optional | appli | integer | Default value : 1 (Bodyscale). This field specifies the device type for which the notification is to be deactivated. See measure/getmeas for supported device types. |
This service has no other answer than the status code that should be zero upon completion.
http://wbsapi.withings.net/notify?action=revoke&userid=29&callbackurl=http%3a%2f%2fwww.yourdomain.net%2fyourCustomApplication.php
{
"status": 0
}
If you encounter implementation issues, have questions or would like to submit new features request or bugs, We encourage you to e-mail us through this contact form under the category “Business inquiries → Partnership and API”.
PLEASE READ THESE TERMS OF USE AND CONDITIONS CAREFULLY BEFORE USING A WITHINGS API.
By accessing and using any Withings API you explicitly agree to comply with and be bound by the following terms and conditions. These terms of use cover the Withings Application Programming Interface (API).
a. Intellectual Property. The Withings API and Withings Brand are the property of Withings, Inc., and subject to the intellectual property rights of Withings, Inc. (c) 2008 Withings, Inc.. All rights reserved.
b. You will not attempt or encourage others to:
Miscellaneous.
Entire Agreement; Amendment. This Agreement contains the entire agreement of the parties with respect to the transaction described in this Agreement, and no prior or simultaneous oral or other written representations or promises shall be a part of this Agreement or otherwise effective. This Agreement may not be amended or released, in whole or in part, except by a document signed by both parties.
Severability. If any provision of this Agreement is held to be unenforceable, the remaining provisions shall be unaffected and shall be construed to the maximum extent possible so as to give effect to the intent of the parties. Each provision of this Agreement is severable from and independent of any other provision. Further, in the event that any remedy hereunder is determined to have failed of its essential purpose, all limitations of liabilities and exclusions of damages shall remain in effect.
1. You may establish a link to the Withings website (www.withings.com), provided that the link does not state or imply that Withings sponsors or endorses any other web site, or presents Withings in a false, misleading, defamatory or derogatory manner. This permission to link to the Withings website does not permit you to use any Withings materials or content, unless separately agreed to in this Agreement or some other agreement with Withings.
2. You may not use "Withings" or any variation thereof in the name of your Developer Applications. You may not use "Withings" or any variation thereof in any domain name, email address, keyword or social media user name.
3. You may make truthful, factual references to Withings in plain-text prose descriptions of your Developer Applications' features and benefits (including references to a Developer Application's interoperability with Withings). For example, the Withings trademark can be used in the manner shown in one of the referential descriptions below:
These phrases can appear near, but must be completely separate and apart from the name/logo of the Developer Application. The font size of phrases using the Withings mark should not be larger than the surrounding font, and should not appear more prominently than the name/logo of the Developer Application.
4. In all materials that contain an approved phrase as set out above, including product packaging, the following legend must also be placed in the "fine print" of such materials. The legend may be in a small type size, but must still be legible: "Withings is a registered trademark and service mark of Withings, Inc. [Insert name of the Developer Application] is designed for use with the Withings platform. This product is not put out by Withings, and Withings does not service or warrant the functionality of this product."
5. You acknowledge and agree that this Agreement does not include the right to use any Withings logo (each a "Withings Logo" and together the "Withings Logos") as part of any brand for the Developer Applications themselves, or as part of any brand(s) or trade name(s) or other designators for your business or non-tested products. The Withings Logo may be used only in the size and format made available to you through Withings' Developer Centre to label or designate data records fetched from the Withings Platform. You may not use the Withings Logos in any other manner, including but not limited to use on promotional materials, standalone technical support or consulting services, or other goods or services without Withings' explicit written permission.