Authentication

You'll need to authenticate your requests to access any of the endpoints in the Atticus API. In this guide, we'll look at how authentication works. Atticus authenticates your API requests with an API key, sent as Basic authentication.

Basic authentication (API key)

With basic authentication, you use an API key (a base64 encoded version of client_id:client_secret) to authenticate your HTTPS requests. Here's how to authenticate using cURL:

Example request with basic auth

curl https://reports.tiro.health/fhir/r5/Patient \
  -u client_id:client_secret \
  --basic

End-user identification in machine-to-machine communication

An API key authenticates your system: requests made with it act as the service account tied to the key, not as a person.

When work must happen as a specific end-user (writing a report, completing a task), do not call the FHIR API with the key directly. Instead, create a session for that user via the Session Management API. The session user is identified in the request body — the user field, or a fhirContext entry of type Practitioner matched by FHIR identifier — and the browser session then carries the user's identity and scopes.

The identifier must match one passed as part of a POST Practitioner request, or the session can create the user on the fly with the https://tiro.health/fhir/role/new context role — see FHIR Context. More information about identifiers in the Atticus FHIR API can be found in the FHIR tips.

Machine-to-machine access

The same API key authenticates machine-to-machine integrations — creating sessions via the Session Management API, background data synchronization with EHR/LIS systems, and automated workflows against the FHIR API.

For code examples in multiple languages, see the API Authentication guide.

Was this page helpful?