API key management: from development to production

What does an API key represent?

An API key lets an application make requests on behalf of your WhatOTP account. Send it using the Authorization: Bearer header. It differs from your account password: you can revoke access for a particular project by managing that project’s key.

WhatOTP shows the full key only once and stores a hash for validation. You cannot retrieve the full value from the dashboard later. If you lose it, create a replacement and update your application configuration.

Store the key on the server

Calling an API from the browser with a secret key exposes that key to people opening the page. Instead, have the browser call your application server, and let the server connect to WhatOTP. Read an environment variable such as WHATOTP_API_KEY only from server code.

In Next.js, values prefixed with NEXT_PUBLIC_ can be included in the client bundle. Do not use this prefix for secret keys. Keep local environment files out of version control and configure production values in your hosting environment’s server settings.

Use a separate key for each environment

Clear names such as development, staging, and production make it easier to identify which application uses a key. If a development key needs revoking, you can do so without disrupting the production application.

Sharing one key across projects may seem convenient, but complicates troubleshooting and configuration changes. Use request history to inspect models and time periods. Avoid writing the key itself into application logs.

• Name keys after their project and environment.
• Revoke keys belonging to unused projects.
• Record request IDs instead of credentials in error logs.

Rotate a key without unnecessary downtime

Create a replacement first, update the application’s server configuration, and send a test request with the new key. After confirming success, revoke the old one. This gives you a chance to detect configuration mistakes before removing existing access.

If you believe a key has been exposed, revoke it promptly. Revoked keys are rejected on new requests. Clear handling of 401 responses in your application makes troubleshooting these changes easier.

Distinguish key errors from connection errors

Not every failure is caused by credentials. A 401 points to authentication, 400 to request formatting, 429 to provider limits, and 503 to service readiness. Start with the status code and status page instead of repeatedly replacing keys.

A support request can start with the request ID, timestamp, and status code. Do not paste a complete API key into your message. These details help locate the relevant record and understand the failure without sharing credentials.