API keys
API keys identify your project when an application sends requests to Geoapify APIs. Requests and credit usage are assigned to the project associated with the key.
How API keys work
MyProjects automatically creates the first API key when you create a project. You can create additional keys at any time.
All keys within a project use the same project plan and quota. Keeping separate keys still lets you apply different restrictions, replace one key without interrupting other integrations, and review usage by key.
Organize your API keys
Use a separate key for each application or environment whenever practical.
| Use a separate key for… | Why it helps |
|---|---|
| Development, staging, and production | Each environment can have its own restrictions |
| Different websites or applications | One integration can be updated without affecting another |
| Browser and server requests | Each request source needs different protection |
| Temporary integrations | The key can be removed when the integration ends |
| Different teams or clients | Ownership and usage are easier to understand |
Give each key a clear description, such as Production website or Server-side geocoding, so collaborators understand where it is used.
If applications need separate billing, ownership, collaborators, or quota management, create separate projects instead.
Create an API key
- Open a project and select API keys.
- Select Create a new API key (+).
- Expand the new key to review its description and restrictions.
- Add suitable restrictions before using the key in an application.
Use the copy action next to a key when you need to add it to an application or request.
Make an API request
Open Try API and generate code from the project's API keys page. Select a Geoapify API and one of the project's keys.
You can try the request, copy its URL, or copy a generated code sample. For endpoint parameters and response formats, see the Geoapify API documentation.
Protect your API keys
Do not commit unrestricted API keys to public source code or publish them in documentation, screenshots, or support messages.
A key used by browser code is visible to the browser user and cannot be treated as a secret. Protect browser keys with suitable referrer or origin restrictions.
For server-side applications, keep the key in an environment variable or secret-management system and restrict it to the server's outgoing IP address when possible.
Choose suitable restrictions
| Restriction | Recommended use |
|---|---|
| Allowed IP addresses | Server requests from known outgoing IPv4 or IPv6 addresses |
| Allowed HTTP referrers | Browser requests from approved pages or URL patterns |
| Allowed origins | Browser requests carrying an approved Origin header |
| CORS Access-Control-Allow-Origin | Controlling which origin browsers allow to read the API response |
IP address and HTTP referrer restrictions support regular-expression patterns. Test every restriction after adding or changing it to ensure legitimate requests still work.
CORS is not an access restriction
The CORS Access-Control-Allow-Origin setting changes the corresponding header in Geoapify responses. Its default value is *.
This setting controls whether a browser allows page code to read a response. It does not restrict who can send requests with the API key. Use Allowed origins, Allowed HTTP referrers, or Allowed IP addresses to protect access.
Rotate an API key
Replace a key when it may have been exposed, when its users change, or as part of your security policy.
- Create a new API key.
- Apply the required restrictions.
- Update and test every application that uses the old key.
- Confirm that requests work with the new key.
- Remove the old key.
Keeping the old key active until the replacement is tested helps avoid an unnecessary interruption.
Remove an API key
Expand the key and select Remove key. Confirm the action only after every dependent application has been updated or stopped.
Removing a key is permanent. Requests using it will fail, but the project and its other API keys remain available.
Frequently asked questions
1Is the first API key created automatically?
Yes. MyProjects creates the first API key when you create a project. You can create more keys from the project's API keys page.
2Should I use the same key for every application?
Using separate keys is recommended. It lets you apply appropriate restrictions, review usage, and replace one credential without affecting unrelated applications.
3Is it safe to use an API key in browser code?
A browser key is visible to users and should not be treated as a secret. Restrict it to the expected HTTP referrers or origins before using it in production.
4Which restriction should I use?
Use IP restrictions for server requests from known outgoing addresses. Use HTTP referrer or origin restrictions for browser applications. When request sources differ, use separate API keys.
5Is the CORS Access-Control-Allow-Origin value an API-key restriction?
No. It controls the response header used by browsers. It does not prevent someone from sending a request with the key. Configure allowed IP addresses, referrers, or origins for access protection.
6Do separate API keys have separate quotas?
No. API keys in the same project share its plan and quota. However, the Statistics page can show usage for an individual key.
7Can I edit the API key value?
No. To change the credential, create a new key, update the application, and remove the old key.
8Can project collaborators manage API keys?
Users with access to a shared project can view and manage its API keys. Coordinate key creation, restriction changes, and removal with other collaborators.
9What should I do if an API key is exposed?
Create a replacement immediately, apply suitable restrictions, update the affected application, and then remove the exposed key. Review project statistics for unexpected activity.
10Can I recover a removed API key?
No. Removed keys cannot be restored. Create a new key and update the affected applications.