Replace an API key without losing track of active applications

Create a replacement, update each consumer, verify the connection and revoke the old credential.

Prepare a MandAPI API-key rotation plan for this application's known consumers. Find configuration variable names, workers and deployment secret references without displaying their values. Plan replacement creation in the dashboard, secret updates, process reloads, a small authorized connection check, old-key revocation and inventory updates. Do not create, revoke or print credentials automatically. Keep endpoint and model settings unchanged unless a separate issue requires a change.

Map the consumers first

Use your application and deployment inventory to identify every place that uses the old key. Include local development, production services, background workers, scheduled jobs and automation credentials. Record secret-store references, not secret values.

A normal rotation can use a short overlap between old and new keys. If the old key is actively exposed, revoke it promptly and restore the affected service with a replacement; the overlap approach is not a reason to leave a compromised key active.

Create and install a replacement

Open your MandAPI dashboard, create a new key and give it a clear application or environment label. Store it directly in the intended secret settings. Apply the restrictions available to your account that fit the application.

Update the application's MANDAPI_API_KEY secret. Do not change the endpoint or model just to rotate a key. Restart or redeploy only the consumers that need to reload their environment; some running processes will continue using their previous value.

Verify the new connection

Run the relevant local configuration checks first. When you authorize a small real request, use a model available to the new key, confirm a valid reply and inspect the corresponding account activity.

For multiple services, keep a checklist with a result per consumer. A successful test from your laptop does not prove that a production worker received the replacement. Do not print both credentials while comparing settings.

Revoke the old key

Once the intended consumers are using the replacement, revoke the old key in the dashboard. Confirm the saved state and observe the application's error reporting. Remove obsolete secret references and update your inventory with the rotation date.

If a normal deployment must be rolled back, use the known working configuration while the old key is still valid. An exposed or revoked key must not be restored as a shortcut; issue another replacement instead.

Check the result

You should have one documented replacement per consumer, a successful connection result where tested and a confirmed revocation decision for the old key. This procedure uses the dashboard; it does not assume a public key-management API or an automatic rotation service.