/people endpoint as an example.
To see all the other endpoints, navigate to the API Reference page
Authentication
All API requests require two authentication components:-
A Bearer token in the
Authorizationheader. This is theauthTokenwe previously generated in the “Getting your API Key” section of this guide. -
A credential ID in the
x-rollout-credential-idheader, this is the Rollout generated credential ID for the user
Where to get the credential ID
There are 2 ways to get the credential ID for your user:-
Provide a callback function to the
onCredentialAddedhook when rendering the Rollout Link authentication UI, in that callback function you can save the credential ID to your database and use it going forward. -
Query the Rollout API to get a given users credential:
sub claim when you generate the authToken, for more info see the Getting your API Key page
Making Requests
Fetch People (GET)
Read another data type
People sync automatically where supported, so the example above needs no extra entity configuration. To read optional types such as notes or tasks, first enable them on the connection. For example, a request toGET /api/notes needs notes: true on the credential identified by x-rollout-credential-id.
Allow the selected data to sync before expecting complete results. A successful authentication or settings update does not mean the sync has finished.
Create Person (POST)
Rate Limiting and Upstream Limits
- Rollout currently applies a coarse tenant-level rate limit (roughly
50 requests/secondper tenant; exact values may evolve). - We do not currently enforce a per-credential limit.
- Most read traffic is served from Rollout’s internal data view, which reduces direct pressure on upstream APIs.
- If an upstream system rate-limits requests, Rollout applies backoff/retry behavior where possible. If a request still cannot be completed in time, you may receive a transient error (for example
429/5xx).
- Retry transient failures with exponential backoff + jitter.
- Make write operations idempotent when possible.
Error Handling
The API uses standard HTTP status codes:-
400: Bad request. For example, the requested entity is not enabled or the connector does not support the operation. Read
errorMessagefor the cause. - 401: Unauthorized (invalid token)
- 403: Forbidden (invalid credentials)
- 404: Not found
- 409: Conflict. This can indicate that data is not ready yet. Allow the sync to progress and retry; timing varies by connector and data volume. Inspect the message for other conflict causes.
- 500: Server error