Qoder shows the full API key only when it is created. You cannot download the same secret again later. Keys are stored securely on the server and are not exposed as plaintext after creation. Follow the practices below to reduce risk.
Scope and privileges
- Set an expiration aligned with your integration; rotate when it expires.
- A key never exceeds the creator’s organization permissions and is limited by the product’s API scope; it cannot grant extra privileges.
Storage
Treat API keys like passwords:
| Do | Why |
|---|
| Avoid email, IM, or plain-text tickets | Easy to forward and retain |
| Avoid leaving keys in shell history | Prefer env vars or prompts |
| Never commit keys to Git | Use .gitignore and secret storage for all repos |
Usage habits
| Do | Why |
|---|
| Read keys from env or a secret manager | Keeps secrets out of source |
| Rotate keys periodically | Limits blast radius |
| Use different keys per environment | Dev / staging / prod isolation |
If a key is exposed
- Revoke or delete the key in the console immediately.
- Create a new key and update all callers.
- If you suspect misuse, notify your security owner and Qoder support with recent
requestId values from error responses.
Apply least privilege: only systems and people that must call the API should receive keys.
