Skip to main content
KINTRA publishes two API surfaces. They cover the same loyalty model, customers, XP, tiers, rewards and redemptions, on-chain assets, internal transactions and analytics, and they differ in who calls them and how a request proves which tenant it belongs to.

​
KINTRA Portal API

The portal API is the surface behind the KINTRA CMS, so its caller is a person signed in to the portal. Most requests carry an Auth0 bearer token in the Authorization header and name the tenant with a {tenantId} segment in the path. Three sit outside that path: GET /user/me, which resolves the signed-in account before a tenant is known and still takes the token, and GET /info and GET /system/masterdata, which take no token either. It also carries operations the gateway surface does not expose, among them API key management, members, attributes, cohorts and customer attributes. Because it is the surface behind the CMS, everything documented under Portal API is something a person on your team can already do by signing in, without writing any code. Reach for the operation when you want it scripted or run on a schedule; reach for the CMS when somebody just needs it done once. Adding a teammate and issuing an API key are the two that most teams do in the CMS and never automate.

​
KINTRA Gateway API

The gateway API is the surface your own backend calls. A request carries X-Tenant-Key, which is the id of an API key you create in the CMS, together with X-Tenant-Timestamp and X-Tenant-Signature. There is no tenant in the path: the key resolves it.

​
Which one to call

Call the gateway API from your servers. It takes a credential your backend can hold and sign with, without a person signed in anywhere, and it is the contract KINTRA supports for partner integrations. Reach for the portal API when you need something the gateway does not carry, such as issuing an API key in the first place, or when you are building against the portal session a person already has.

​
Before you send anything

Export the base URL for this environment once, then every sample on the reference pages runs against it without editing:
Every sample and every operation page on this site sends to that same address, because the reference and this snippet are rendered from one environment record.

​
The playground cannot sign a gateway request

Each operation page carries an interactive playground, and on a gateway operation it cannot produce a working request on its own. X-Tenant-Signature is an HMAC over the request, and the playground has no way to compute one, so pressing Send with only your key returns 401.
To use the playground against a gateway operation, compute the timestamp and the signature yourself and paste them into the X-Tenant-Timestamp and X-Tenant-Signature fields before sending. The simpler path is the samples. Every gateway operation page carries a cURL sample and a TypeScript sample that build the signing string, sign it and send the request in one piece. Both run as printed once you have exported KINTRA_API and replaced the placeholder key, secret and identifiers.

​
How to read the reference

The two surfaces are documented at different depths, on purpose. Gateway operations carry the fuller prose: what the operation does, when to call it, what comes back, and the errors worth knowing about. That is the surface your backend integrates against, so it takes the detail. A portal operation that duplicates a gateway capability carries a summary and a pointer to the gateway entry rather than a second description of the same behaviour. One explanation means one place to correct when the behaviour changes, instead of two that drift. Portal operations with no gateway equivalent carry a summary and a description of their own. The three API key operations are the exception and carry the fuller treatment, because issuing a key is the step every gateway integration starts from.