stackin
Back to blog
Get building

Environments

homologation and production are a property of the key, not a request parameter — here's what that means in practice.

Every key — sdk or api — is created for exactly one environment, homologation or production, chosen at creation and fixed for that key's whole lifetime. It can't be changed later; the fix for "wrong environment" is creating a new key, not editing the existing one.

There's no environment field anywhere in a request or an SDK call. The key you authenticate with is what decides where the document goes — which removes an entire class of bug where a misconfigured flag accidentally sends a test document to the real government authorizer, or vice versa.

homologation isn't a local mock — it talks to the same authorizer validation flow as production, just flagged as a test transmission. That means the rejection rules, required fields, and response shapes you see in homologation are the real ones, not an approximation that quietly drifts from what production actually enforces.

It's also free and has no volume limit, so there's no pressure to ration test issuances or share a single test company across a team — issue as much as you need while building and testing.

A company can hold up to 3 keys total, any mix of context (sdk/api) and environment (homologation/production). A common pattern is one sdk/homologation key for local development, one api/homologation key for staging or CI, and one api/production (or sdk/production) key for what actually goes live.