What Is a Database API and How Do You Use One to Read and Write Data?

A database API is an HTTP interface that lets your code read and write records in a database without connecting to the database engine directly. You send a request to a URL, authenticate, and get structured data back — usually JSON. This differs from a database driver (like a PostgreSQL client library), which speaks the database's native protocol and requires a persistent connection plus credentials to the database itself. Use a database API when you want controlled, network-accessible access for apps, integrations, or scripts; use a driver when you control the server and need raw speed or full SQL.

Baserow, an open-source no-code database platform, exposes this kind of API on top of its tables, and its developer docs list an OpenAPI specification, a plugin API, and Docker install options — useful reference points for what a database API typically includes.

Database API vs. general web API vs. database driver

The key distinction: a database API is a web API whose resources map to tables, rows, and fields. A general web API might return a weather forecast; a database API returns the rows you stored.

Common API styles

• REST — resources at URLs (/api/rows/), HTTP verbs for actions (GET, POST, PATCH, DELETE). Most no-code and low-code databases default to this.
• GraphQL — one endpoint, you specify exactly which fields you want. Good when clients need different shapes of the same data.
• Generated CRUD endpoints — the platform auto-creates list/create/read/update/delete routes for each table. Baserow's OpenAPI specification documents this pattern, so you can generate client code instead of hand-writing requests.

Reading and writing records: the basic flow

The steps below are the general pattern. Exact URLs and field names come from your platform's API docs.

1. Get an authentication token

Most database APIs issue a token tied to a user or a scoped integration. You send it on every request, typically as a header:

Authorization: Token YOUR_API_TOKEN

Some platforms use Bearer instead of Token. Check the docs — using the wrong scheme returns 401.

2. List records (read)

GET /api/database/rows/table/{table_id}/?user_field_names=true
Authorization: Token YOUR_API_TOKEN

Expected result: a JSON object with a results array (the rows) and pagination metadata like count, next, and previous. The user_field_names=true style parameter is common — it makes the response use your human-readable field names instead of internal field IDs.

3. Create a record (write)

POST /api/database/rows/table/{table_id}/?user_field_names=true
Authorization: Token YOUR_API_TOKEN
Content-Type: application/json

{ "Name": "Acme Corp", "Status": "Active" }

Expected result: 200/201 with the created row, including its new row ID. Save that ID — you need it for updates and deletes.

4. Update a record

PATCH /api/database/rows/table/{table_id}/{row_id}/?user_field_names=true
Authorization: Token YOUR_API_TOKEN
Content-Type: application/json

{ "Status": "Closed" }

PATCH changes only the fields you send; PUT typically replaces the whole row. Prefer PATCH unless you intend to overwrite everything.

Pagination, filtering, and rate limits

These are where most real integrations break.

• Pagination — list endpoints return a page at a time (often 100 rows). Loop using the next URL until it's null, or pass page and size parameters. Never assume one request returns all rows.
• Filtering — most APIs accept query parameters like ?filter__field_123__equal=Active or a search parameter. Filtering server-side is faster and cheaper than downloading everything and filtering in your code.
• Rate limits — APIs cap requests per minute/hour. When you exceed the cap you get 429 Too Many Requests, often with a Retry-After header. Batch writes where the API supports it, and add backoff on 429.

Troubleshooting common failures

A frequent mistake: using the table's name in the URL instead of its numeric ID. The API almost always wants the ID.

When a database API is the right tool

Choose a database API when you need apps, scripts, or third-party tools to read and write records over the network with scoped permissions and without exposing the database engine. Choose a direct driver when you own the server, need complex joins or transactions, and can manage connection pooling yourself. If you're on a no-code platform like Baserow, the API is the intended integration path — start from its OpenAPI specification so your client stays in sync with the schema.