Managing API Keys
How to manage API keys via the developer console
Last updated
How to manage API keys via the developer console
Last updated
It is important to safeguard your API keys. Please read this guide on API Key management for tips on how to manage them effectively.
You can configure a short alphanumeric nickname for each API key you create. We recommend you set this to something meaningful that helps you identify the purpose of the API key, e.g. 'my-app-prod'.
We use the nickname when measuring usage and in the future you will be able to identify usage per api key using this field.
The API key description can be used to provide additional details about how the key is used in your projects.
You may disable a key temporarily via the developer console. Keys that wish to retain, e.g. for occasional testing, but which aren't in regular use should be disabled to prevent misuse.
You may delete an API Key via the console. For improved security of your account, we recommend you rotate API keys from time to time by creating a new key and then deleting its predecessor once the new key has been provisioned in your project.
You can test your API key by clicking the test button:
This will send a request to for the current Julian Day and display the result in your browser. This is a quick way to check that the key is working.
Note: the request may be rejected if you have allowed origin or IP rules configured.
Each API key may have zero or more entitlements associated with it. On a Free plan, you will see no entitlements for your API key. Generally, on paid plans, the entitlement should match your plan level, e.g. for a Starter plan, you should see the starter entitlement provisioned for your API keys.
API key entitlement provisioning is handled automatically by our systems, for example, on purchasing a subscription or on creating a new API key via the developer console. However, we show the entitlements here so you can visually confirm that everything is configured correctly.
Additionally, some users may see additional entitlements for their keys, such as research for education and research use.
This feature is available with the PRO plan or higher.
You may optionally configure one or more allowed origin rules for each API key. This is done in the developer console. Edit the API key to add or remove allowed origin rules:
For example, you may specify example.com to allow requests only with that Origin host, as provided in the request headers. You can also write rules that include a single wildcard, placed anywhere in the string, e.g.:
*.example.com
api.*.example.com
example.*
Upon updating the key, any configured origins are shown on the API key page.
If you leave the Allowed Origins field empty, requests are allowed from any origin.
If you configure one or more origin rules, then any request that does not include an Origin header will be rejected with a 401 response.
Multiple rules may be specified, separated by a semicolon. You may also specify IP addresses, but be aware that these rules apply to the origin header only and not to the requesting IP address.
We recommend specifying as few rules as possible to avoid any performance impacts (although these are likely to be minimal in most cases). You may wish to consider creating additional API keys to avoid the need to specify multiple rules.
Requests that do not pass allowed origin rules a rejected with a 403 Forbiddenresponse.
This feature is available with the PRO plan or higher.
You may optionally configure one or more allowed IP rules for each API key. This is done in the developer console. Edit the API key to add or remove allowed IP rules:
You can specify a single IP, a list of IPs, or a block of addresses in CIDR format. Any configured Allowed IPs are shown in the console:
If you leave the Allowed IP Addresses field empty, requests are allowed from any IP.
We check the requesting IP address and if any rules are present, evaluate whether it is allowed or not. Rejected requests receive a 403 Forbidden response.
If you configure a rule with your local IP address, but see that your requests are rejected, you may need to configure both IPv4 and IPv6 addresses as allowed, depending on how your requests are sent over the network.
For example, a request made in a browser may be sent over IPv6, whereas a request made via an application running on your computer may be made over IPv4.
