Skip to main content
Rotate API keys on a schedule, after staff changes, after any suspected exposure, and before changing deployment ownership. Rotate the signing key when the partner private key changes or may have been exposed.

​
Rotate an API key

1

Create a replacement key

Open the API application and choose Create replacement key. Nuvera returns a new one-time API key and marks existing active keys as expiring when a grace window is used.
2

Store the new key

Store the new key in the partner secret manager. Do not paste it into tickets, chat, docs, logs, proof artifacts, or screenshots.
3

Deploy the new key

Deploy the service with the new x-api-key value while continuing to sign requests with the current private key.
4

Verify production traffic

Confirm that successful REST requests are using the new key. Check last-used metadata in the application screen.
5

Revoke the old key

Revoke the old key after the new deployment is verified. If there is a suspected exposure, revoke immediately and redeploy without a grace window.

​
Rotate a signing key

Rotating the signing key changes the RSA key pair used for the Authorization JWT.
  1. Generate a new RSA private/public key pair outside Nuvera or in the browser.
  2. Store the new private key in the partner key manager.
  3. Replace the application signing public key in Nuvera.
  4. Deploy the service with the matching private key.
  5. Send a signed test request and verify success.
  6. Remove the old private key from service configuration after rollout.
Nuvera stores only the public key fingerprint and public key PEM. Existing raw API keys and private keys are never displayed.

​
Emergency disablement

If a partner service is compromised, disable the API application from the partner app or ask a Nuvera admin to disable it from the organization hub. A disabled application rejects authentication even when the API key and JWT are otherwise valid.

​
Audit and rollback expectations

Application creation, permission changes, enabled/disabled state changes, signing-key replacements, key creation, expiring-key updates, and key revocations are recorded in audit history. For rollback:
  • If the new key is bad and the old key is still active or expiring, switch service configuration back to the old key and investigate.
  • If the old key was revoked, create another replacement key and deploy it.
  • If the signing key was replaced with the wrong public key, replace it again with the public key matching the private key currently deployed by the service.