API keys

ImageKit authenticates API requests using API keys. We return an error if you don't include your key when making an API request or use an incorrect or outdated one.

Authentication to the API is performed via HTTP Basic Auth. Provide your private API key as the basic auth username value. You do not need to provide a password.

For example, you can provide the private API key in a curl request as:

curl https://api.imagekit.io/v1/files \ 
-u your_private_api_key:
# The colon prevents the curl from asking for a password.

You can view your API keys in the ImageKit.io dashboard under the developer options.

There are two types of API keys:

• Standard keys: A standard API key has read and write access to all the APIs. At any time, you can have a maximum of 5 standard keys.
• Restricted key: A restricted API key allows only the minimum level of access that you specify across all the APIs listed above. The three access levels are: None, Read only, and Read and write. For example, if you set Read-only permission for media access for your restricted key, you cannot use it to perform any upload, update, or delete operation. You can only perform operations like list and search files, get file details, get file metadata, etc. At any time, you can have a maximum of 5 restricted keys.

This is used to identify your account in certain client-side file upload implementations. It is not meant to be a secret; you can publish this in client-side Javascript code or an Android or iPhone app. It is only used in upload API integration on client-side applications.

It always starts with the public_ prefix to make it easy to identify.

This should be kept confidential and only stored on your servers. When you make an API request, a private key is used to authenticate your account.

It always starts with private_ prefix to make it easy to identify.

It is strongly recommended that your private key be kept safe and confidential. To help keep your API keys secure, follow these best practices:

1. Do not embed API keys directly in your code. API keys that are embedded in code can be accidentally exposed to the public. For example, you may forget to remove the keys from the code that you share. Instead of embedding your API keys in your applications, store them in environment variables or in files outside of your application's source tree.
2. Do not store API keys in files inside your application's source tree. If you do, keep the files outside your application's source tree to help ensure your keys do not end up in your source code control system. This is particularly important if you use a public source code management system like GitHub.
3. Regularly rotate your API keys. If you suspect your API keys have been compromised, rotate them immediately. You can also rotate your keys periodically as a security best practice.
4. Prefer using restricted keys over standard keys. Restricted keys limit the scope of access to your account, reducing the risk of unauthorized access.

If an API key is compromised, you should roll that pair immediately and start using the newly generated keys. The newly generated pair has the same resource access permissions as the old one.

You can choose when to expire the existing key:

• Immediately
• In 1 hour
• In 24 hours
• In 3 days
• In 7 days

The expiry period you choose, blocks and expires the existing key after the specified time period. Regardless of the expiry period, you can use the new key immediately.

You can delete any existing API key in your account. However, your account will always have at least one pair of active standard keys.

By default, the private key is masked for security reasons. You can click on the reveal icon next to the private key and enter your password to authorize and reveal the private keys.

If you have logged in using SSO, you will first need to set the password for your account under the profile section.

If you have logged in using a one-time link sent to your email, you must set the password for your account under the profile section and then reveal the private key.

You can:

• Create a new restricted API key and specify its resource access permissions.
• Update resource access permissions on any existing restricted API keys.

The three access levels across any resource are: None, Read only, and Read and write.