Overview
Replace an API key by creating a new one and updating the integration that uses it. Editing a key’s name or Read-only setting does not rotate its secret.
At a glance |
|
Who can do this | Super Users or Organization › Administrate, plus the person responsible for the external integration. |
Where | Configuration › API › API Keys and the integration’s secure configuration |
Works on | Backend (web), Public API |
Availability | Mobaro Public API access enabled for the organization |
💡 Why this matters: A controlled replacement keeps credential ownership clear and reduces the chance that retiring one key unexpectedly stops several integrations.
Before you start
Identify every system using the old key from your integration records. The Backend shows key names, prefixes and creation dates, not a per-key request history. If a key is exposed, follow your organization’s incident procedure; a routine staged changeover may not be appropriate.
Walkthrough
1. Identify the old key
Open Configuration › API › API Keys and match the Name and Prefix to the integration’s record. Confirm the integration owner and whether it needs write access. Do not copy the actual secret into a ticket or article.
2. Create the replacement
Select Create, enter a distinct Name such as “Reporting feed — replacement” and leave Read-only enabled for a read-only feed. Save. Write access is available only where the organization’s API access permits it.
3. Store the new secret securely
The API key created dialog shows the full key once. Copy it directly into the approved secrets store before selecting Understood. The full key cannot be recovered later from the Backend.
4. Retire the old key after verification
Have the integration owner update its secure configuration and verify the expected requests using the new key, including a scheduled run where relevant. Then select the old key by Name and Prefix, choose Delete and confirm. Check the next integration run after removal.
Check the outcome
The integration sends the key in the x-api-key header. Both keys remain usable until the old one is deleted. Every key can read organization-wide data; Read-only restricts writes, not which Locations or datasets can be read. See API access scope and key management.
Best practices
Keep one named key per integration.
Record the owner and rotation date without recording the secret.
Verify a real scheduled run before considering the routine changeover complete.
Frequently asked questions
Can I recover the old full key from its prefix?
No. The prefix identifies it but cannot reveal the secret. Create a replacement if the full key was not stored.
Can I restrict the replacement to one dataset?
No. API keys have organization-wide read access. Read-only prevents writes; it is not a dataset or Location restriction.
Does deleting a key affect the replacement?
They are separate keys. Deleting the old one stops requests that still use that old secret, so update and verify every dependent integration first.