Your API keys are the credentials that authenticate all requests from your system to Quidax. A compromised API key is equivalent to giving an attacker access to your integration. 

The rules for API key handling

• Never expose your secret key in client-side code. Your API secret key should only exist in your backend environment. It must never appear in JavaScript that runs in a browser, in a mobile application binary, or anywhere that an end user or third party could extract it.
• Store keys in environment variables or a secrets manager. Do not hardcode API keys in your codebase. Use environment variables (e.g., .env files excluded from version control) or a dedicated secrets management tool such as AWS Secrets Manager, HashiCorp Vault, or GCP Secret Manager.
• Never commit API keys to version control. Check your .gitignore before your first commit and audit your repository history if you are unsure whether keys have been exposed in past commits.
• Enable IP whitelisting for your API keys. Restrict API access to trusted IP addresses (e.g., your backend servers or infrastructure) to prevent unauthorised requests. 
• Rotate keys immediately if you suspect compromise. If your secret key is accidentally exposed — pushed to a public repository, included in a log, or shared incorrectly — regenerate it from your Quidax Business dashboard immediately. A new key is active as soon as it is generated; your old key is simultaneously invalidated.
• Use separate keys for sandbox and production. Do not use your live API key for testing. Keep sandbox and production credentials in separate, clearly labelled environments.
• Restrict key access within your team. Only the engineers who require direct API access should have access to production credentials. Use your team’s internal access management tools to enforce this.