Keep API keys secure
Use the narrowest credential that fits the job and keep raw tokens out of public code.
API security is mostly about using the right credential in the right place. A server can safely hold a full account API key. Shipped software and public JavaScript should not.
Zwely helps by separating account API keys from product-scoped validation tokens and by storing only hashes after the raw value is shown once.
Credential safety basics
Use account API keys only on servers
Account keys start with zwy_ and can access supported account API resources. Keep them in server environment variables or a secret manager, never in shipped software or public JavaScript.
Use validation tokens for software
Validation tokens start with zvl_ and are scoped to one product, making them safer for license checks from an app. They should still be treated carefully, but they are intentionally less powerful.
Store raw values once
Zwely shows new credentials once and stores only hashes afterward. If you close the reveal without saving the raw value, create a new credential and revoke the unused one.
Revoke old credentials
Revoke keys when a developer leaves, a server is replaced, an integration is retired, or a token may have been exposed. Revoked credentials stop working immediately.
Build around rate limits
API limits protect accounts and checkout reliability. Handle 429 responses with backoff instead of retrying in a tight loop.
Good to know
- The API reference includes current rate limits, request examples, response examples, and error shapes.