Skip to main content
A fully functional REST API is automatically generated from your Collection configs.
The REST API is a fully functional HTTP client that allows you to interact with your Documents in a RESTful manner. It supports all CRUD operations and is equipped with automatic pagination, depth, and sorting. All FrogBot API routes are mounted and prefixed to your config’s routes.api URL segment (default: /api). For example, if you have a Collection called pages, you can fetch its documents directly from the browser or any HTTP client:
To enhance DX, you can use FrogBot SDK to query your REST API. REST query parameters:
  • depth - automatically populates relationships and uploads
  • locale - retrieves document(s) in a specific locale
  • fallback-locale - specifies a fallback locale if no locale value exists
  • select - specifies which fields to include in the result
  • populate - specifies which fields to include in the result from populated documents
  • limit - limits the number of documents returned
  • page - specifies which page to get documents from when used with a limit
  • sort - specifies the field(s) to use to sort the returned documents by
  • where - specifies advanced filters to use to query documents
  • joins - specifies the custom request for each join field by name of the field. joins[field]=false leaves that field out; joins=false has no effect

Collections

Each collection is mounted using its slug value. For example, if a collection’s slug is users, all corresponding routes will be mounted on /api/users. Note: Collection slugs must be formatted in kebab-case All CRUD operations are exposed as follows:

Auth Operations

Auth enabled collections are also given the following endpoints:

Preferences

In addition to the dynamically generated endpoints above, FrogBot has REST endpoints to manage admin user preferences for data specific to the authenticated user.

Custom Endpoints

Additional REST API endpoints can be added to your application by providing an array of endpoints in various places within a FrogBot Config. Custom endpoints are useful for adding additional middleware on existing routes or for building custom functionality into FrogBot apps and plugins. Endpoints can be added at the top of the FrogBot Config or to collections and accessed through the API and slugs you have configured.
Custom endpoints are not authenticated by default. You are responsible for securing your own endpoints.
Each endpoint object needs to have: Example:
req will have the frogbot object and can be used inside your endpoint handlers for making calls like req.frogbot.find() that will make use of Access Control and Hooks.

Helpful tips

req.data Data is not automatically appended to the request. You can read the body data by calling await req.json(). Or you could use our helper function that mutates the request and appends data and file if found.
req.locale & req.fallbackLocale The locale and the fallback locale are not automatically appended to custom endpoint requests. If you would like to add them you can use this helper function.
headersWithCors By default, custom endpoints don’t handle CORS headers in responses. The headersWithCors function checks the FrogBot config and sets the appropriate CORS headers in the response accordingly.

Method Override for GET Requests

FrogBot supports a method override feature that allows you to send GET requests using the HTTP POST method. This can be particularly useful in scenarios when the query string in a regular GET request is too long.

How to Use

To use this feature, include the X-HTTP-Method-Override header set to GET in your POST request. The parameters should be sent in the body of the request with the Content-Type set to application/x-www-form-urlencoded. For cross-origin requests from a browser, add the header to the allowed CORS headers: cors: { origins: ['https://app.example.com'], headers: ['X-HTTP-Method-Override'] }.

Example

Here is an example of how to use the method override to perform a GET request:

Using Method Override (POST)

Equivalent Regular GET Request

Passing as JSON

When using X-HTTP-Method-Override, it expects the body to be a query string. If you want to pass JSON instead, you can set the Content-Type to application/json and include the JSON body in the request.

Example

This can be more efficient for large JSON payloads, as you avoid converting data to and from query strings. However, only certain endpoints support this. Supported endpoints will read the parsed body under a data property, instead of reading from query parameters as with standard GET requests.

FrogBot REST API SDK

@frogbotai/sdk is a typed client for the FrogBot REST API. It works in any frontend: a Next.js app, a Vite or plain browser app, a mobile app, or a script.
The SDK package is currently in beta and may be subject to change in minor versions updates prior to being stable.

Install and types

Install the SDK, and install frogbot as a dev dependency for its types:
frogbot is only used for types and is never bundled into your frontend. Without it, the SDK still runs, but its results are untyped (any), and TypeScript reports that the generated types file can’t find the frogbot module. Copy your app’s generated types file, frogbot-types.ts, into the frontend. Once it’s part of the project, every SDK call is typed from it: collection slugs, where fields, select, and the documents you get back. A misspelled collection slug is a compile error. Before types are generated, the SDK still works, and documents are typed as plain objects. Types need skipLibCheck: true in your tsconfig.json. FrogBot’s starter already sets it. Without it, TypeScript reports errors from third-party packages that frogbot’s types reference.
createFrogBotSDK() accepts: To pick the types explicitly, for example when a frontend talks to more than one FrogBot app, pass the generated Config:
In a monorepo, share the file through a types package instead of copying it. For example, an @acme/types package whose index.ts re-exports the generated file:
Add @acme/types and frogbot as dev dependencies of each frontend, and import Config from @acme/types.

Operations

These examples use a posts collection with title and slug fields and drafts enabled. Find documents with where, select, sort, and pagination. The query string is built for you:
Find a document by ID. Pass draft: true for the latest draft, which needs an authenticated request. With disableErrors: true, a missing document returns null instead of throwing:
Count, create, update, and delete:
Update and delete with id return the document. With where, they return { docs, errors }. Read and restore versions:
Run a search against one of the collection’s search indexes. Hits are typed documents with their score:
Search several collections with one query using searchMany. This example also uses a pages collection with a content index. Results come back in the order you list the collections, one ranked list each, with limit applied per collection:
Each entry’s where suggests that collection’s fields, and each list’s hits are typed as that collection’s documents. When you loop over results, checking result.collection narrows them. FrogBot doesn’t order hits from different collections against each other; see Search several collections. Every method takes standard RequestInit options, such as headers or credentials, as its last argument. Non-success responses throw FrogBotSDKError, with the HTTP status and the server’s errors:

Authentication

The SDK does not store login tokens. Log in, then send the token on later requests with a JWT header:
Request-specific headers in the second argument are merged with the configured headers. refreshToken, forgotPassword, resetPassword, and verifyEmail follow the same pattern; see authentication operations. Send an API key as a Bearer token:
In the browser, use session cookies instead by including credentials on every request:
Cross-origin cookie requests require the server’s CORS and cookie configuration.

Uploads

Create a document in an upload collection with a File, or a URL to fetch the file from, and its data:
This example requires an upload-enabled media collection with an alt field. For an upload that needs no data, upload(collection, file) is a shorthand. This example targets your app’s files collection:
upload() returns the stored document, typed as FrogBotUpload: its id, filename, and mimeType, plus every other field the collection returns, such as url, filesize, or a chat asset’s text. Those other fields are typed unknown, so check their type before use. A rejected upload throws FrogBotSDKError.

Custom endpoints

Use request(path, init) for custom endpoints. It returns a Web Response and throws FrogBotSDKError for non-success responses. The json option serializes the body and sets Content-Type:

Options reference

Every method’s last argument, init, takes standard RequestInit options that are merged into the request. Its headers override the configured headers. find(options, init?) findByID(options, init?) count(options, init?) create(options, init?) update(options, init?) delete(options, init?) findVersions(options, init?) findVersionByID(options, init?) restoreVersion(options, init?) search(options, init?) searchMany(options, init?) Each entry in collections accepts: The server always enforces the caller’s access. A collection the caller can’t read fails the whole call with a 403 FrogBotSDKError. login(options, init?) me(options, init?) and refreshToken(options, init?) forgotPassword(options, init?) Skipping the email and setting the token’s expiration are only available in the Local API, so a public caller can’t change how password resets work. resetPassword(options, init?) verifyEmail(options, init?) request(path, init?)