Rest API

Note: This page is a technical reference for the Rest API. If you're starting a project with Prismic, we recommend you use a user-friendly guide for the technology of your choice:

You can also read a beginner-friendly introduction to the Prismic API:

The Prismic Rest API is an extremely fast, flexible, and powerful engine for your content.

Your repository has a Repository API Endpoint. This endpoint has information about your repository, including your repository's refs, which are necessary to make a query to the Rest API.

Your Repository API Endpoint is available here:

The Rest API is available here:

To access the Rest API endpoint, you will need a ref. The ref specifies what version of your content to query. A basic query, including a ref, might look like this:

Query URLs, like the one above, will expire as the ref goes out of date. The ref must be up-to-date.

All of the Rest API options are encoded as URL search parameters. A URL search parameter is a key-value pair. The value must be encoded as a URL component. You can encode the value using JavaScript's encodeURIComponent() function. Prior to encoding, the key-value pair might look like this:

After encoding the value, it will look like this:

One or more of these parameters can be joined with ampersands to form a query string:

Append your query string to the API endpoint with a question mark:

JavaScript has a built-in URL() constructor to manage search parameters:

However, there is no need to create and manipulate URLs manually. @prismicio/client will handle the technical parts of performing API requests (including fetching your ref):

You can use the below parameters to construct your query string.

A ref identifies a specific version of your content (for instance: draft, published, or scheduled). Refs are available at the Repository API:

To query your content, you will need to perform one query to get your current ref (which is a short token) and then a second query — using that ref — to get your content. This ensures that the content returned is the correct version and up-to-date.

A long, secret string required to query content in private repositories. Available in your Prismic repository settings. Required for private repositories.

The query parameter (q) accepts a set of filters (encoded as a URI component) as its value. Each filter is enclosed in square brackets, and the set is enclosed in square brackets.

The API will return documents that match every filter if the set includes multiple filters or the query string contains various query parameters.

Most filters accept a path to denote the field being examined and then one or more values to compare in the search. The paths can take two formats, based on the filter: document.[meta-value] or my.[custom-type].[field]. See the following reference:

Each path can be used with specific document fields. This pivot table shows what field types can be used with what paths:

An essential query parameter to search for a document of the type "article" will look like this:

A query parameter to search for a document of type "article," last published in 2020, will look like this:

To test queries you can use the Prismic API Browser accessible at https://your-repo-name.prismic.io/api/v2. (Learn more about the API Browser.)

You won't need to construct query URLs because we have development kits for the most popular web development frameworks. These kits offer helper functions for querying the API. You can learn more about querying with various technologies in our technology guides.

Here's an example of what a filter query would look like in the API Browser, with our JavaScript kit, and as a URL:

Here is the full list of filters:

Checks that the path matches the described value exactly. It takes a single value for a field at the top level of the document (not in Slices) or an array (only for tags).

To query by a content relationship, supply the document ID as the value.

Available values:

Examples:

Checks that the path doesn't match the provided value exactly. It takes a single value or an array. (Arrays are only accepted for tags.)

Accepted values:

Example:

Accepts an array of values and checks whether the fragment matches any of the values in the array. When used with the ID or UID field, it will not necessarily return the documents in the order given in the array.

Accepted values:

Example:

Checks whether a document's ID or UID is in an array of IDs or UIDs. It works the same as the any filter but is much faster because it is only used for IDs and UIDs.

Also, unlike the any filter, it returns the documents in the same order as the given array.

Accepted values:

Example with IDs:

Example with UIDs:

Checks if a string is found inside a whole document or within a specific field on a document.

fulltext will search for a single term, passed as a string, or for multiple terms, passed as a string of terms with spaces between them. With multiple terms, the API will return documents that contain all terms.

The search is not case-sensitive and it matches based on the root word, so a search for "Dogs" will include "dog."

The search considers rich text, title, key text, select, and UID fields. It ignores image alt text in rich text fields. It doesn't matter if the field is inside a group, a Slice, or a Slice repeatable section.

The search is ordered by relevance, with more priority given to rich text content, especially headings.

Accepted values:

Example:

The has filter checks whether a fragment has a value. It will return all the documents of the specified type that contain a value for the specified field.

Works for all content types except groups and Slices.

Accepted values:

Example:

The missing filter checks if a fragment doesn't have a value. It will return all the documents of the specified type that do not contain a value for the specified field.

Works for all content types except groups and Slices.

Note that this filter will restrict the results to the custom type implied in the path.

Accepted values:

Example:

The similar filter takes the ID of a document, and returns a list of documents with similar content. This allows you to build an automated content discovery feature (for example, a "Related posts" section).

Accepted values:

Example:

The geopointNear filter checks that the value in the path is within the radius of the given coordinates. Distance is measured in kilometers.

The near filter will order the results from nearest to farthest from the given coordinates.

Accepted values:

Example:

The numberLessThan filter checks that the value in the number field is less than the value passed into the filter.

This is a strict less-than operator, it will not give values equal to the specified value.

Accepted values:

Example:

The numberGreaterThan filter checks that the value in the number field is greater than the value passed into the filter.

This is a strict greater-than operator, it will not give values equal to the specified value.

Accepted values:

Example:

The numberInRange filter checks that the value in the path is within the two values passed into the filter.

This is an inclusive search, it will include values equal to the upper and lower limits.

Accepted values:

Example:

Prismic has sixteen filters for dates and times. The "after" and "before" filters will not include a date or time equal to the given value. The "between" filters will include dates and times equal to the given values.

Accepted values:

Example:

This example combines the month and year filters. This query will return content published in May 2020:

This option specifies what field to order your results by, and whether to order them ascending or descending.

Use an orderings object to sort your query results in a given order. The following example will sort blog posts by the date they were originally published, in descending order:

Specify the field with the path my.[custom-type].[field]:

By default, the results will be ordered from lowest to highest. To order results highest to lowest, add desc:

To order by multiple fields, use a comma-separated list in the API and an object in JavaScript. The results will be ordered by the first path. When the value of the first path is the same for multiple results, they will be ordered by the second path, and so on.

In this example, products will be sorted by price. Products with the same price will then be sorted by title.

Documents also have a first_publication_date and last_publication_date. These can also be used with orderings:

This option works with orderings to return documents after the one specified.

For example, imagine if you have a query that returns the following document IDs (in this order):

If you add the after option with the a value of "VkRmhykAAFA6PoBj", like this,

your query will return:

By reversing the orderings in your query, you can use this same method to retrieve all the documents before the specified document.

GraphQuery is a query option that enables you to make advanced queries. It allows for selective fetching (only retrieving specific fields) and deep fetching (retrieving content from linked documents and content relationships).

The Rest API accepts an encoded GraphQuery string. You can encode the string with JavaScript's built-in encodeURIComponent() function or with a web service. Prismic's development kits will automatically encode the string for you.

Request URLs to the Rest API are limited to 2048 characters. You can reduce your string length by using line breaks with no spaces or tabs, or you can use a white space removal tool.

Here's an example:

Read the complete reference for GraphQuery:

Please note: fetch is deprecated in favor of graphQuery.

This option is used to make queries faster by only retrieving the specified field(s).

To retrieve a single field, specify it with [custom-type].[field]:

To retrieve multiple fields, use array syntax:

This option allows you to retrieve a specific content field from a linked document and add it to the document response object.

fetchLinks can not retrieve the following fields:

• Rich text (anything other than the first element)
• Any field in a Slice (only the Slice Zone)

To retrieve the linked content, use the format [linked-document-type].[field-on-linked-doc]:

To retrieve multiple fields, use array syntax:

To retrieve a content field inside a group field, use the format [linked-document-type].[group-on-linked-doc].[field-on-linked-doc]:

To retrieve the Slice Zone, use the format [linked-document-type].body:

This option allows you to specify what locale you would like to retrieve content from. By default, the API will return content from your master locale.

To specify a particular locale, pass the locale code:

To retrieve all locales, pass the wildcard value *:

This option defines the maximum number of documents that the API will return for your query. It accepts a number. The default is 20, and the maximum is 100.

The page option defines the pagination for the result of your query. It defaults to 1, corresponding to the first page.

The integration field allows you to integrate data from third-party services. integrationFieldsRef specifies the version of Integration Field data embedded in Prismic documents to query. You can retrieve the latest integrationFieldsRef for your repository by making a call to the Repository Endpoint, just like you do to retrieve a standard ref. If you omit integrationFieldsRef, you might not get the freshest data from the integration.

The routes option — also called the route resolver — resolves URL paths for every document based on rules defined by the client. If no routes option is specified, the url property will be null.

The route resolver has the properties type, uid, lang, and resolvers. The resolvers property has access to the variables :uid, :lang, and :[resolver]. :lang and :[resolver] can be marked as optional with a question mark ?.

For a full definition, see the route resolver article:

Here is a simple route resolver:

The brokenRoute option defines a URL path for broken links.

Broken links occur when a document with inbound content relationships or links is deleted. In the linking documents, the link or content relationship field shows up with type: broken and isBroken: true. The routes option will not generate a url property for broken links.

The path defined with brokenRoute will populate in the url property of broken link and content relationship fields.