Credentials

There is no credential CRUD on this API — not create, not list, not rotate, not deactivate — and this is a permanent architectural decision, not a gap waiting to be filled.

Why

A partner access token is short-lived (5 minutes) specifically so a leaked token can’t do much damage. If the API that issues those tokens could ALSO create or rotate the underlying long-lived credential, a single leaked 5-minute token could be used to mint itself a brand-new, permanent credential — turning a bounded, self-expiring leak into permanent account takeover, or into a lockout if an attacker rotates your only credential and deactivates the original. Keeping credential management on a separate, human-operated plane closes that door structurally: possessing a live API token never gets you the ability to manage credentials.

Where credential management actually lives

All credential lifecycle actions — generate, list, rotate, deactivate — are self-service through the Linra Omni Portal dashboard, under API Credentials in your partner account area. This requires a dashboard login (a human, with the api.credentials permission on their role), not an API token.

From there you can:

• Generate a credential per environment (staging and production side by side) — the secret is shown exactly once.
• List your credentials — client ID, environment, creation date, active status, last used.
• Rotate — generates a new credential and deactivates the old one. There is no in-place secret update; treat rotation as “get a new credential, then retire the old one,” not “change this credential’s secret.”
• Deactivate a credential immediately.

Every generate/rotate action triggers a security notification email to your account — treat an unexpected one as a signal to investigate immediately.

Zero-downtime rotation

Because rotation creates a new, independent credential rather than mutating the old one in place, you can rotate without an outage:

1. Generate a new credential (or use “rotate” on an existing one) — you now hold two valid credentials simultaneously.
2. Update your integration’s configuration to the new clientId/clientSecret and deploy.
3. Once you’ve confirmed the new credential is live and working (a successful POST /api/v1/auth/token call), deactivate the old credential from the dashboard.

Up to 3 active credentials per (partner, environment) pair are allowed, so don’t accumulate old credentials indefinitely — deactivate the old one promptly after confirming the new one works.

What this means for your integration

Treat your clientId/clientSecret pair as a long-lived, manually-managed secret (like a database password), not something your integration code ever creates or modifies — no code path in your integration should ever need to call anything resembling a “create credential” or “rotate credential” endpoint, because none exists.