Atla public API
The Atla API lets another system read and write an organization's staffing data: providers
(clinicians and other staff), facilities, needs (open staffing requests), orders (shifts) and
shift events (check-in, break, check-out). It is the same /api/v1 the Atla web app and mobile app use,
reached with an API key instead of a sign-in.
https://app.atlahq.com/api/v1
Who it is for
- A VMS or scheduling system that creates needs and books shifts in Atla.
- An ATS or HRIS that keeps providers in sync.
- A back office or BI tool that pulls shifts and time-clock events.
How it works
- An admin creates a key in Atla under Settings → Organization → API keys, picks its scopes and an expiry date. The full key is shown once.
- Your system sends the key as a bearer token on every request.
- The key acts as the organization that created it, limited to its scopes. Everything it does is written to the organization's audit log under the key's own name.
curl -H "Authorization: Bearer atla_live_..." https://app.atlahq.com/api/v1/profile
Where to go next
- Getting started: create a key and make the first request.
- Authentication and scopes: what a key can and cannot do.
- Conventions and errors: ids, dates, pagination, rate limits, status codes.
- Resources: every endpoint with request and response shapes.
- Interactive reference: the OpenAPI document, browsable.
Stability
Only the routes in openapi.json are part of the public contract, and they change
additively: new fields and new routes may appear, existing ones keep their meaning. Anything you can
see the web app call but which is not in the reference is not available to keys and may change without
notice. Changes are listed in the API changelog.