Authentication
One key per merchant, sent as a bearer token.
Every /api/partner call carries a merchant API key:
Authorization: Bearer <key>The key identifies the merchant. There is no merchant id in any partner URL and no way to name one in a body — whatever the key belongs to is the only account the call can reach.
Getting a key
An OWNER mints it from the dashboard under Тохиргоо → Интеграц
(POST /api/dashboard/tenant/api-key, session-authenticated). A MANAGER cannot: the key issues
every ticket the venue sells, so it sits with whoever signed the integration.
A Nubisoft platform admin can also install one while onboarding the merchant
(POST /api/admin/tenants/{tenantId}/api-key) — the same key, the same one column, so whichever
side mints last is the key that works. Either way the response is identical:
{
"apiKey": "hK3n8Qw2...Zx",
"createdAt": "2026-08-26T04:29:35.323Z"
}Shown once
Only a SHA-256 hash is stored. Nothing — not the dashboard, not the backend team — can read the key back. Put it straight into your secret store.
GET /api/dashboard/tenant/api-key reports whether a key exists and when it was made, never the key
itself. DELETE revokes.
Rotation
Minting again replaces what is there. One column holds one hash, so the old key stops working the instant the new one exists — there is no overlap window. Plan a rotation as a brief coordinated swap, or expect failed calls in between.
Failures
Everything that is not a valid key is the same answer:
{ "status": 401, "message": "send your API key as Authorization: Bearer" }No header, a malformed header, an unknown key and a revoked key are indistinguishable by design — a caller holding a wrong key learns nothing about whether some other key would have worked. There is no role on this surface, so there is no 403.
Using a valid key against another merchant's externalRef is a 404, not a 403: the lookup is
scoped to your own account, so you cannot discover whether that reference exists elsewhere.