About the Yammer REST API
The Yammer REST API enables message posting, feed access, and many other capabilities. It supports both Yammer OAuth 2 (legacy) and Azure Active Directory (AAD) tokens.
Versioning
Only version 1.0 endpoints are supported. You should avoid using APIs which are not documented on this site because they are subject to change at any time.
The API version is shown in the URLs of the endpoint e.g. /api/v1.
Admin Actions
In order to perform administrative API actions, such as creating and deleting users, the access token should belong to a verified admin user in paid Yammer networks.
Response format
Yammer can return JSON or XML in API responses. When no extension is provided, some older endpoints may default to returning XML. It is strongly recommended that you use the JSON response format at all times.
Developers should expect that new elements or attributes may be added to the API responses. The ordering of items within the data structures is not guaranteed.
For example, the order of the foo and bar items in the excerpts below might be swapped in the same version of the API:
JSON
{ "things": { "foo": "Foo!", "bar": "Bar!" } }
XML
<things><foo>Foo!</foo> <bar>Bar!</bar></things>
If elements are removed, we will typically release a new version of the API.
Getting bulk content
The Data Export API is the recommended option for getting content in bulk, such as fetching all message content for a group in a compliance or analytics app.
Contrast the Data Export API with the messages REST endpoint which returns a subset of messages. All messages may not be returned because threads can have a very large number of messages. This difference a benefit when developing a responsive end user application which is the focus of the REST API.
Application which need frequent access to Yammer content should aggressively cache API responses to avoid repeat requests for the same data.
Yammer API Rate Limts
REST API calls are subject to rate-limiting. Exceeding any rate limit will result in all endpoints returning a status code of 429 (Too Many Requests). Rate limits are set per user per app.
The table below shows the four rate-limits which should be considered.
| Endpoint type | Rate limits | Additional notes |
|---|---|---|
| Autocomplete | 10 requests in 10 seconds | The autocomplete resources allow for more frequent polling than other resources, as they are meant to enable realtime responses for a user as they type. See the autocomplete section to understand how to use this feature. |
| Messages | 10 requests in 30 seconds | When polling for messages, do not exceed one poll per minute. Apps that poll excessively will be blocked. However, your app may sometimes need to fetch messages more frequently e.g. if a user flips between “following”, “sent” and “received” feeds quickly: this is allowed for a few requests. Do not attempt to decrease message latency in your app by checking for new messages more frequently than once per minute. |
| Notifications | 10 requests in 30 seconds | |
| All other endpoints | 10 requests in 30 seconds | Rate limits for all other resources are tuned to virtually guarantee that a normally functioning client serving even a heavy Yammer user will not run into rate limit problems. |