Contexts
How one partner serves many customers — the partner, context, and product-tenant model.
You are a partner. You serve many of your own customers, and each customer is a context you thread. A context maps — in the gateway's private bookkeeping — to that customer's downstream product tenant. The gateway holds the mapping and never any customer's positions.
Why contexts exist
Without contexts, every customer would need their own integration. With them, one partner integration serves all your customers. The same axis serves a developer's multi-customer use and a packaged product's multi-tenant use alike — one mechanism, not two.
The resolution path
On a call, you select the acting context with the One-Context header. The gateway
resolves it:
- partner → identifies you from your signing credential
- context → the customer you named
- product-tenant → the downstream tenant bound to that context for the product
- threaded credential → the product's own credential, attached by the gateway
The product receives only its own credential — never your One-API credential. The gateway threads the right downstream credential for the resolved context.
Creating and binding
Create a context with POST /contexts, passing your own opaque reference (stored
and returned verbatim, never interpreted). Downstream product tenants bind to the
context as you provision them — see Provisioning.
A context with a single bound tenant resolves automatically; with several, name the
one you mean via One-Context.
Next
- Entitlements — what a partner is allowed to reach.
- Provisioning — binding a product tenant to a context.