# API Keys

Typesense allows you to create API Keys with fine-grain access control. You can restrict access on both a per-collection and per-action level.

WARNING

We will be using the initial bootstrap key that you started Typesense with (via --api-key) to create additional keys. It's strongly recommended that you don't use the bootstrap API key directly in your production applications. Instead you want to generate an appropriately-scoped key for the application at hand.

# Create an API Key

# Admin Key

Let's begin by creating an API key that allows you to do all operations, i.e. it's effectively an admin key and is equivalent to the key that you start Typesense with (via --api-key).

By setting both actions and collections to a wildcard ['*'] scope, we're able to create an admin key that gives you universal access. However, you should refrain from creating such widely scoped keys.

WARNING

The generated key is only returned during creation. You want to store this key carefully in a secure place.

# Search-only API Key

Let's now see how we can create a search-only key that allows you to limit the key's scope to only the search action, and also for only a specific collection.

By setting the actions scope to ["documents:search"] and the collections scope to ["companies"], we can generate a key that is allowed to only conduct searches on the companies collection.

# Sample Response

The collection names can contain regular expressions. For example, if you have multiple collections that begin with org_ and want to have a common key for all of them, you can define the permissions this way:

{
  "description": "Key for searching org collections.",
  "actions": [
    "documents:search"
  ],
  "collections": [
    "org_.*"
  ]
}

# Definition

POST ${TYPESENSE_HOST}/keys

# Arguments

Parameter	Required	Description
actions	yes	List of allowed actions. See next table for possible values.
collections	yes	List of collections that this key is scoped to. Supports regex. Eg: `coll.*` will match all collections that have "coll" in their name.
description	yes	Internal description to identify what the key is for
value	no	By default Typesense will auto-generate a random key for you, when this parameter is not specified. If you need to use a particular string as the key, you can mention it using this parameter when creating the key.
expires_at	no	Unix timestamp (opens new window) until which the key is valid.

# Sample actions

Action	Description
`documents:search`	Allows only search requests.
`documents:get`	Allows fetching a single document.
`collections:delete`	Allows a collection to be deleted.
`collections:create`	Allows a collection to be created.
`collections:*`	Allow all kinds of collection related operations.
`*`	Allows all operations.

# Retrieve an API Key

Retrieve (metadata about) a key.

# Sample Response

Notice how only the key prefix is returned when you retrieve a key. Due to security reasons, only the create endpoint returns the full API key.

# Definition

GET ${TYPESENSE_HOST}/keys/:id

# List all Keys

Retrieve (metadata about) all keys.

# Sample Response

Notice how only the key prefix is returned when you retrieve a key. Due to security reasons, only the create endpoint returns the full API key.

# Definition

GET ${TYPESENSE_HOST}/keys/

# Delete API Key

Delete an API key given its ID.

# Sample Response

# Definition

DELETE ${TYPESENSE_HOST}/keys/:id

# Generate Scoped Search Key

You can generate scoped search API keys that have embedded search parameters in them. This is useful in a few different scenarios:

You can index data from multiple users/customers in a single Typesense collection (aka multi-tenancy) and create scoped search keys with embedded filter_by parameters that only allow users access to their own subset of data.
You can embed any search parameters (for eg: exclude_fields or limit_hits) to prevent users from being able to modify it client-side.

When you use these scoped search keys in a search API call, the parameters you embedded in them will be automatically applied by Typesense and users will not be able to override them.

# Example

Let's take the first use-case of storing data from multiple users in a single collection.

First you'd add an array field called accessible_to_user_ids to each document in your collection, listing all the users who should have access to the document in that field.
Then when a user with say user_id: 1 lands on your search experience, you'd generate a unique scoped search API key for them (on your backend server), with an embedded filter of filter_by: accessible_to_user_ids:=1.

When you make a search API call with this scoped search API key, Typesense will automatically apply the filter_by, so the user will effectively only have access to search through documents that have their own user_id listed in the accessible_to_user_ids field.

Now let's say you also don't want users to know the entire list of users_ids that have access to a document, you can also embed exclude_fields: accessible_to_user_ids in the scoped API key, so it doesn't get returned in the response.

# Role-based access Advanced

Let's take another scenario where an organization has many users and users can be a part of one or more roles (eg: admin, sales, support, etc). You can store all records/documents belonging to all organizations and users in a single collection and conditionally allow a given logged-in user to only search through their own organization's data and only for the subset of data their role grants them access to, using Scoped API keys.

First you'd add a field called accessible_to_organization_id to each document in your collection.
Add another array field called accessible_to_roles to each document, and add all the roles within that organization that have access to this document.
Generate a parent search API key for each organization using the API Keys endpoint.
Now when a user belonging to organization_id: 1 with a role of say sales and marketing logs in, you would generate a Scoped API Key using the organization's Parent Search API Key and embedded filters of filter_by: accessible_to_organization_id:=1 && accessible_to_roles:=[sales,marketing]

When you make a search API call with this scoped search API key, Typesense will automatically apply the filter_by, so the user will effectively only have access to search through documents that have their organization_id and role(s) listed in documents.

Now, when a user leaves an organization, for added security, you can delete the organization's parent search API Key and generate a new one, and use that to generate scoped search API keys for users logging in, in the future. Once a parent Search API Key is revoked, all scoped API keys that were generated with it are invalidated automatically.

TIP

Once a parent Search API Key is revoked, all scoped API keys that were generated with it are invalidated automatically.

# Usage

We can generate scoped search API keys without having to make any calls to the Typesense server. We use an API key that we previously generated with a search scope (only), create an HMAC digest of the parameters with this key and use that as the API key. Our client libraries handle this logic for you, but you can also generate scoped search API keys from the command line.

# Sample Response

You can also set a custom expires_at for a scoped API key. The expiration for a scoped API key should be less than the expiration of the parent API key with which it is generated.

WARNING

If you have documents in a collection that only a certain subset of users should have access to, remember to never expose your main search key client-side, since exposing the main search key will allow users to query all documents without your embedded search parameters / filters.

← Documents Curation →