Skip to main content
KINTRA runs the loyalty program inside your product. Your company is a tenant, the people who use your product are customers, and each customer holds an XP balance. Customers earn XP for what they do, move between tiers as that balance grows, and spend XP on rewards you define, which produces a redemption. KINTRA holds the ledger, the tiers, the rewards and the on-chain assets tied to them, and every part of it is reachable over an HTTP API.

​
What is here

Quickstart

An API key to a registered customer in two signed requests, with the signing string built line by line.

Concepts

The six pages that define the model: tenants, customers, XP and the ledger, tiers, rewards and redemptions, and on-chain XP.

API reference

Both API surfaces, each labelled with who calls it and what credential it takes, plus a signed sample on every gateway operation.

Request conventions

The error envelope and the codes to branch on, the idempotency header a write needs, and what a rate limit looks like.

​
What to do first

If you are wiring a backend to KINTRA, start at the quickstart. It gets a signed request working before it explains anything, which is the order the failures arrive in. Then read request conventions, because the first write from a new integration usually fails on a header rather than on the body. If you are running the program rather than integrating it, start with tenants and XP and the ledger. Most of what the portal API documents is something you can already do by signing in to the KINTRA CMS, and the API reference overview says which operations those are. If you are choosing which surface to call, KINTRA publishes a portal API and a server-to-server gateway API, and they take different credentials. Compare the two.