An API key often starts in one developer's environment and gradually reaches a deployment platform, a worker and a scheduled job. When it is time to rotate the credential, the hard part is usually identifying every place that still uses it.
Inventory consumers before changing the key
List the application services, workers and environments that send through Sendar. Identify the owner of each secret configuration. Separate development from production where your account setup allows, and avoid distributing a production credential just to make local testing convenient.
Keep the key on the server. Public repository history, client-side bundles, screenshots and copied logs are all places where a secret can escape its intended boundary. If a key is exposed, treat removal from the visible file as only one part of the response.
Roll out the replacement deliberately
Create the replacement through the Sendar dashboard and update the appropriate secret stores. Deploy or restart consumers as required by their environment loading behaviour. Changing a platform setting does not always change the value already held by a running process.
Check authentication and application health using a controlled process. Do not trigger unrelated customer emails solely to see whether the deployment is alive. A local mock can validate request construction; a deliberately authorised send is a separate verification step.
Revoke and watch for stragglers
After the intended consumers use the replacement, revoke the old key. Watch for authentication errors that reveal a forgotten worker or scheduled job. Record the change time and affected services so support can connect a new error to the rotation.
If the old credential was compromised, the urgency and sequence may differ: follow your incident process and prioritise stopping unauthorised access. Routine overlap is not a reason to leave a compromised key active.
Reduce the next rotation's cost
Maintain a credential-consumer inventory in your deployment documentation, without storing the credentials themselves there. Use consistent environment names and a documented owner for updates. Rotation becomes much less disruptive when it is a repeatable operational procedure rather than a search through old messages and configuration files.