Authentication

Bearer tokens are all most integrations need

Every tenant-aware route takes a single header:

1 Authorization: Bearer <jwt>

user tokens are already scoped to a single tenant, so the bearer header is everything a user request needs. The SDKs set it for you when you pass token at client construction.

Send a request

$ curl "$BASE_URL/locations?page=1&limit=50" \
>   -H "Authorization: Bearer $ACCESS_TOKEN"

What is tenant-scoped

Most endpoints that create, list, update, or operate on locations and chargers are tenant-scoped, including:

/locations
/chargers
/chargers/{charger_id}/...
/locations/{location_id}/chargers/...

Catalog reads are authenticated but are not tied to a specific tenant.

Failure modes

Status	Meaning
`401`	Missing or invalid bearer token
`403`	Wrong role or missing tenant scope
`422`	Request shape fails schema validation

Admin tokens (internal only)

admin tokens act across tenants and must pick one explicitly via X-Organization-Id. This only applies to internal OCPPLAB admin integrators — skip this section if you use a user token.

$ curl "$BASE_URL/locations?page=1&limit=50" \
>   -H "Authorization: Bearer $ADMIN_TOKEN" \
>   -H "X-Organization-Id: $ORG_ID"

Rules:

Admin tokens must send X-Organization-Id on tenant-scoped routes.
User tokens must never send X-Organization-Id — the backend rejects it.

Next step

Continue to Common workflows for end-to-end examples.

$	curl "$BASE_URL/locations?page=1&limit=50" \
>	-H "Authorization: Bearer $ACCESS_TOKEN"

$	curl "$BASE_URL/locations?page=1&limit=50" \
>	-H "Authorization: Bearer $ADMIN_TOKEN" \
>	-H "X-Organization-Id: $ORG_ID"