Authentication
Authenticate every request with your institution’s secret key in the X-Spring-API-Key header.
The key determines which institution’s data you reach. There is no tenant or institution parameter on any endpoint — if you find yourself wanting one, you have the wrong key.
Regions
Each region is a separate deployment with its own data. Call the host your institution belongs to.
A key issued for one region does not work against the other.
Permissions
Each endpoint requires either read or write permission, carried by the key itself. A key with read-only permission calling a create endpoint gets 403, not 401 — the credential was understood, it just is not allowed to do that.
When authentication fails
Two things to code around, because they differ from the rest of the API.
A 401 returns a plain-text reason, not the JSON error object documented under Errors. Parse defensively — a client that assumes JSON on every non-2xx will throw on its own error path.
An unrecognised key returns 400, not 401. If you are branching on status alone, treat 400 and 401 together as “the credential is wrong” rather than assuming 400 always means a malformed request body.
Keep keys server-side
An API key grants full read or write access to an institution’s data for as long as it is valid. Never ship one in a mobile app, a browser bundle, or anything a user can read. There is no scoping mechanism that makes a client-side key safe.
No sandbox yet
Every key is a live key. There is no test mode and no sandbox host, so any create or update you make while building an integration changes real data for your institution. Until that changes, do your first writes against records you are willing to clean up, and use dry runs to validate a request shape without persisting it.