Authentication
Authenticate every REST request with an API key and pin the API version.
Every Raster REST request is authenticated with an API key and pinned to a specific API version. Both are sent as HTTP headers.
API keys
REST and GraphQL share the same key system: a key created in your organization settings works for both APIs, with the same per-library access levels.
To create, scope, regenerate, or revoke a key, follow the full walkthrough in GraphQL Authentication → API keys. The short version:
- In Organization settings → API keys, generate a new key.
- Enable Read access for every library the key should reach. Add Write access if the key will upload or delete assets.
- Copy the key once — it is shown only at creation.
Treat API keys like passwords. Never commit them to source control or expose them in client-side code. If a key leaks, regenerate it immediately — the old value stops working at once.
Access levels
Each key carries a per-library access level. Every endpoint checks the level before running:
| Level | Grants |
|---|---|
| Read | GET /libraries, GET /assets, GET /tags. |
| Write | POST /assets, DELETE /assets. Includes read. |
A request that targets a library the key cannot reach fails with 404 and
API_KEY_NOT_AUTHORIZED_FOR_LIBRARY — the same response a request for a
library that does not exist would get. The status is deliberately 404,
not 403, so a key without access cannot probe library existence by
comparing error codes. See Errors for the full
rationale.
The Authorization header
Send your key as a bearer token:
Authorization: Bearer <API_KEY>A missing or malformed Authorization header rejects the request with 401
and UNAUTHENTICATED. An Authorization header that is present but carries
a token unknown to the target organization returns 401 INVALID_API_KEY
instead.
POST /libraries is anonymous — it mints
a new API key, so it needs no Authorization header.
The Api-Version header
Every request must declare the API version it was written against:
Api-Version: 2026-05-20The current version is 2026-05-20. A missing or empty Api-Version header
rejects the request with 400 and API_VERSION_REQUIRED.
Every response carries Vary: Api-Version, so HTTP caches (your CDN, browser,
intermediaries) key bodies per version. Two clients on different versions
never see each other's response bodies.
When a breaking change ships, the new value goes in the changelog. Existing integrations keep working against their pinned version until they choose to migrate.
A complete request
A full authenticated REST request looks like this:
curl --request GET \
--header 'Authorization: Bearer <API_KEY>' \
--header 'Api-Version: 2026-05-20' \
--url 'https://api.raster.app/organizations/acme-co/libraries'Requirements
- HTTPS only. Requests over plain HTTP are rejected.
- API key required. Requests without a valid
Authorization: Bearerare rejected with401— except the anonymousPOST /librariesendpoint, which mints a key. Api-Versionrequired. Requests without a non-emptyApi-Versionheader are rejected with400.- Scope matters. The key must have the right access level for every library it touches.