API Backends

Build custom APIs with Hono, test them in the API console, and store data in D1

An API Backend is an app in your project that serves your own API. It’s built with Hono and TypeScript, and the AI agent writes the routes, database schema, and tests for you. Instead of a visual preview, the builder opens an API console where you can see every endpoint, send test requests, and read the logs.

Your mobile apps, web apps, and websites in the same project can share one API Backend.

Adding an API Backend

API Backends live inside a project. To add one:

Open your project and click Add app.
Under Backend & data, choose API Backend.
Choose a database (see below).
Describe what the API should do and click Create app, or click Create without a prompt to start from the default setup.

You need the Editor role or higher to add apps to a project. A project can hold more than one API Backend.

Choosing a database

Option	What you get
D1	A managed SQL database at the edge, created for you. This is the default. See D1 database.
Supabase	A dedicated, managed Postgres database.
External Postgres	Connect a Postgres database you already have.
None	No database. You can add one later.

For External Postgres, enter a Development connection URL (it starts with postgres:// or postgresql://). You can also add a Migration URL if migrations should use a different connection. You can connect staging and production databases later. Credentials are encrypted when they’re saved.

To add a database to an API Backend created with None, open APIs & Data and go to the Database tab. Choose Provision Cloudflare D1, Provision Supabase, or Connect Postgres. Once a database has data in it, you can’t switch it to a different provider automatically.

How your API is built

The agent follows a consistent structure, so your API stays easy to test and document:

Hono on Cloudflare Workers. Your API runs on the Workers runtime, which has no filesystem and doesn’t support long-running processes.
OpenAPI routes. Each route declares its request and response schemas, and the API serves an OpenAPI document at /doc. The API console and API Docs are both built from this document, so a route only shows up there if it’s declared this way.
Versioned paths. Public routes live under /v1. /doc and the /healthz health check are always public.
API keys by default. Every other route requires an API key, including new ones the agent adds.
Database migrations in your repo. Schema changes are written as migrations and saved with your code, so every environment gets the same schema when you publish.
Tests. The agent can write and run tests that use the same Workers runtime.

Store secrets such as third-party API keys as environment variables in Build Config, not in your code.

API console

The API console is the main view of an API Backend. It has three parts: Endpoints on the left, the request playground in the center with Request Logs below it, and the agent on the right. On a phone, use the tabs along the bottom (Endpoints, Console, Agent) to switch between them.

Endpoints

The Endpoints list updates on its own as the agent adds or changes routes. Endpoints are grouped by tag, or by the first part of their path, and each shows its method, path, and summary. Use Search endpoints… to filter by path, method, summary, or tag.

If the list is empty, check the message it shows. The development server may still be starting, or the API may have no routes yet. If the OpenAPI document is missing or invalid, ask the agent to fix it.

Sending requests

Select an endpoint to open it in the playground. Fill in any path parameters in the request bar, then click Send. Requests always go to your development server.

Tab	Use it to
Params	Add query parameters.
Headers	Add request headers. `Content-Type` is filled in for requests with a body.
Body	Edit the JSON body. It starts with the example from the endpoint’s schema, and Reset to example restores it.
Auth	See the development API key the playground attaches for you. Turn on Send without API key to check that the endpoint rejects unauthorized requests.

The response shows the status, how long the request took, and the response size, with Body and Headers tabs. Click Copy as cURL to copy the request as a command you can run elsewhere. The copied command has a placeholder where your API key goes.

The playground remembers each endpoint’s request and last response while you switch between endpoints. Viewers can browse endpoints but need the Editor role to send requests.

Request Logs

Open Request Logs from the bar at the bottom of the playground.

Requests lists recent requests, newest first, with the method, path, status, duration, and time. Expand a request to see the logs it produced. Your latest request from the playground is highlighted.
Raw shows the full development server log.

API Docs

API Docs in the builder navigation shows documentation generated from your API’s OpenAPI document. For each endpoint you get its parameters, request body, responses, and whether it requires an API key. Wide screens also show a cURL example you can copy. Everyone with access to the app can read API Docs.

D1 database

D1 is a managed SQL database from Cloudflare. When your API Backend uses D1, Draftbit creates the database for you. Your API reaches it directly, so there’s no connection URL to manage.

Each environment has its own database:

Development is created with the app and is the one the agent and the API console use.
Staging and Production are created the first time you publish to that environment.

Browsing your data

There are two ways to open the D1 workspace:

On your project page, click Manage D1 on the API Backend’s card.
In the builder, open APIs & Data and go to the Database tab.

You need the Editor role or higher. Pick an environment, then use the sections:

Section	What it shows
Overview	The database’s storage, table count, and settings.
Tables	Your tables. Select one to browse its first 100 rows.
SQL	Run SQL queries. Results show up to 500 rows.
Metrics	Reads, writes, rows read and written, and the queries using the most database time, for today, the last 7 days, or the last 30 days.

Table browsing is read-only. In SQL, a query that can change data or schema needs a second click to confirm. Before you can run SQL against Staging or Production, Draftbit asks you to confirm, and for production you type PRODUCTION.

API keys

Requests to your API need an active key in the x-api-key header. An Authorization: Bearer header with the key also works. Keys are scoped to one environment.

Draftbit creates a Development key for you, and publishing to staging or production creates a key for that environment if it doesn’t have one. That means a published API is protected from the start.

Manage keys in Publishing, on the API tab:

Create Key makes a new key for the environment you choose. Copy it when it appears. You can reveal it again later from the key list.
Copy key copies a key.
Rotate key revokes a key and issues a replacement.
Revoke key turns a key off.

Changes to the development key apply right away. Changes to staging and production keys apply the next time you publish to that environment. If an environment has no active keys, its API accepts all requests.

Publishing

Your API runs in three environments:

Environment	Where it runs
Development	Your sandbox. It restarts as you build, and it’s what the API console calls.
Staging	A deployed version with its own stable URL.
Production	A deployed version with its own stable URL.

To deploy, click Publish in the top bar, then Publish in the API row. Name the version, choose Staging or Production, and start the publish. Publishing runs your database migrations against that environment’s database first.

After a publish, the API tab shows the environment’s URL, which you can copy, and its version. Custom domains aren’t available for API Backends. See Publishing for more about versions.

Connecting your apps

Apps in the same project can use your API Backend:

When you add a mobile app, web app, or website to a project that already has an API Backend, setup asks which backend to use. If there’s only one, it’s picked for you.
When you create a project with D1 or External Postgres, the new app is connected automatically.

Connecting adds two development environment variables to the app, one for the API’s URL and one for its development key. Their names start with the app’s prefix, for example VITE_API_URL and VITE_API_KEY for a web app, EXPO_PUBLIC_ for a mobile app, or PUBLIC_ for a website. You’ll find them in Build Config. Set the staging and production values yourself when you’re ready to publish.

The agent in each app knows about the others. The backend’s agent knows which apps will call it, and your app’s agent can read the backend’s API.