API keys play a vital role in how your project interacts with Aptos Build services. They help with authentication, rate limiting, and usage tracking—ensuring your application runs smoothly and securely. Here’s a breakdown of how API keys work and how to use them properly:
Why API Keys Matter
If you don’t use an API key, your client is considered anonymous, and subject to much stricter rate limits. That means slower performance, limited access, and a higher risk of failure during peak times.
To get the best experience and avoid disruptions, always authenticate with an API key.
One Key Per Resource (Usually)
By default, each resource (like a node or indexer) should have only one API key. However, Aptos Build lets you create multiple keys for a single resource to enable key rotation—a best practice in case a key is ever leaked.
Client vs Server Keys
When generating a new API key, you’ll be asked if it’s for Client Usage (i.e. exposed to the public):
- Client Usage (Public)
For dApps, mobile apps, or browser extensions. You must:- Whitelist approved URLs or extension IDs.
- Set a per-IP rate limit (e.g., 10,000 CUs per 5 minutes).
- Use the
Clientkey format:AG-XXXX...
- Server Usage (Private)
For backend-only contexts. These keys should never be exposed publicly and require no origin whitelisting.
Format:aptoslabs_XXXX...
Anonymous Access (Use Sparingly)
Some Aptos Build APIs accept requests without a key, but these are:
- Limited per IP and per origin
- Far more restrictive than authenticated access
Use anonymous requests only for low-traffic or experimental use cases.
Learn More
Want details about usage limits, costs, and monitoring?
Check the Billing & System Limits documentation
TL;DR:
Use API keys for better performance, security, and access. Choose the right type (Client or Server), rotate them if needed, and avoid anonymous usage for anything serious.