Rotate the event-signing HMAC secret
Rotate the HMAC secret used to sign events delivered to the partner's queue. Either supply a partner-generated high-entropy secret (≥32 bytes, base64 or hex) or omit it to have the server generate one and return it exactly once. The previous secret remains valid for the grace window so signature verifiers can be rolled without dropping events. **Status: not yet implemented.** Returns `503 service_unavailable` with `Retry-After: 86400`. The outbound event publisher is not live yet — contact your TAIH integration contact.
Authorization
OrgId Tenant identifier resolved by Kong from the authenticated taih-tenant-key. Required on partner-scoped routes (e.g. POST /v1/users, POST /v1/auth/token, /v1/admin/*). In production Kong injects this header after validating the tenant key; local-dev callers must set it themselves.
In: header
Header Parameters
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
curl -X POST "https://loading/v1/auth/signing-secret/rotate" \ -H "Content-Type: application/json" \ -d '{}'{
"data": {
"signing_secret_rotated_at": "string",
"previous_secret_expires_at": "string"
}
}{
"detail": [
{
"loc": [
"string"
],
"msg": "string",
"type": "string"
}
]
}Rotate the tenant API key
Issue a new tenant API key while keeping the previous key valid for a configurable grace period (default 24h, max 7 days). Partners deploy the new key to every backend service before the old one is revoked, enabling zero-downtime rotation. The new key is returned exactly once — store it immediately in a secret manager. **Status: not yet implemented.** Returns `503 service_unavailable` with `Retry-After: 86400`. Manual rotation is available — contact your TAIH integration contact.
Create a partner-linked user
Register a partner-scoped `user_id` (UUID) so subsequent member-scoped calls can be routed against it. `user_id` is the only required field; `first_name`, `last_name`, and `email` are optional seed values. The server keeps an internal identifier but never exposes it — the partner-supplied `user_id` is the canonical handle and is reused in every `/v1/users/{user_id}/*` path going forward.