Authentication
Every request to a /v1 endpoint carries an API key in a header. There are no OAuth flows and no per-request signing — just the key.
The X-API-Key header
Authenticate by sending your key in the X-API-Key request header. It is not a bearer token and does not go in the Authorization header:
X-API-Key: trs_x8Q…your-key…A full request looks like this:
curl https://api.territas.com/v1/underwrite \
-H "X-API-Key: $TERRITAS_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "address": "…", "purchase_price": 450000, "annual_rent": 42000, "annual_taxes": 6200, "annual_insurance_base": 1800 }'Only /health is public. Any /v1 request without a valid key is rejected with 401 Unauthorized:
{
"detail": "Invalid or missing API key"
}How keys work
- Keys are prefixed
trs_followed by a long random token, so they’re easy to spot in logs and secret scanners. - We store only a SHA-256 hash of your key — never the key itself. That means the full value is shown once, at creation. Copy it then; if you lose it, rotate rather than recover.
- Keys don’t expire. A key stays valid until you revoke it, so rotation is something you do on your schedule, not something the clock forces.
- Your tier travels with the key — it sets your rate limit and your metered usage. See Plans & limits.
Rotating a key
Create the replacement first, deploy it, then revoke the old key once nothing is using it. Because keys never expire and multiple can be active at once, you can rotate with zero downtime.
Calling from a browser
CORS is enabled for the Territas web origins and allows the Content-Type and X-API-Key headers. Even so, a key that ships to the browser is a key you’ve published — prefer calling Territas from your backend and keeping the key server-side.

