canonical: https://jentic.com/apis/ninoxdb.de/ninoxdb

# Ninoxdb De Ninox API

This page describes a curated, agent-optimized Jentic OpenAPI specification for Ninox API (ninoxdb.de variant), covering 14 operations and kept validated and agent-ready. Ninox also publishes its own OpenAPI document, which describes a different generation of the API built around workspace and module resources, carries 23 operations, and declares no server URL, so the two specs share no paths and Jentic keeps this teams-and-databases variant alongside it. Ninox is a low-code database platform popular with European teams under the ninoxdb.de domain. This spec covers the same REST surface as the ninox.com listing but adds GET endpoints for individual teams, individual tables, and table fields, plus file download and upload routes for record attachments. The team-database-table-record hierarchy is unchanged, and authentication is the same bearer token issued from the Ninox account settings.

## For AI agents

Read and write records, manage tables, and upload file attachments on Ninox through 14 endpoints under api.ninox.com/v1.

## Scope

Does not handle Ninox formula scripting, view configuration, or user permissions - use for Ninox records, table schema reads, and record file attachments only.

## Capabilities

- Inspect a single team or table through GET `/teams/{teamId}` and `/tables/{tableId}`
- List the field metadata for a Ninox table through `/tables/{tableId}/fields`
- Page through, create, update, and delete records through /records routes
- Upload an attachment to a record through POST `/records/{recordId}/files/{fileName}`
- Download a record attachment through GET `/records/{recordId}/files/{fileName}`
- Walk the team-database-table hierarchy with dedicated GET endpoints
- Issue all calls under the same bearer token used by the ninox.com listing

## Use cases

### Document attachments on records

Many internal tools store contracts, receipts, or scans alongside the structured row. POST `/teams/{teamId}/databases/{databaseId}/tables/{tableId}/records/{recordId}/files/{fileName}` uploads an attachment, and the matching GET endpoint downloads it. The schema model on /fields lets the agent confirm the table has a file-typed column before pushing the upload.

Example prompt: POST a contract.pdf attachment to `/teams/{teamId}/databases/{databaseId}/tables/{tableId}/records/{recordId}/files/contract.pdf` and verify the response confirms the upload.

### Schema-aware record sync

Before pushing rows from another system, an integration can call GET `/tables/{tableId}/fields` to learn the current Ninox schema, mapping its source columns onto the matching Ninox fields. Then POST /records inserts new rows and PUT `/records/{recordId}` updates existing ones with confidence that the field names will match.

Example prompt: Call GET `/tables/{tableId}/fields` to retrieve the column list, then POST /records with a fields object whose keys match the returned field names.

### Internal CRUD app back-end

A custom internal app running over Ninox uses the records endpoints as its CRUD layer. List with GET /records, create with POST /records, read a single row with GET `/records/{recordId}`, update with PUT, and delete with DELETE. The team and database IDs in the URL keep tenants isolated.

Example prompt: Call PUT `/teams/{teamId}/databases/{databaseId}/tables/{tableId}/records/{recordId}` with fields {Status: 'Closed'} and confirm a 200 response.

### AI agent operating a Ninox-backed app

An AI agent running an internal-ops workflow can read, write, and attach files on Ninox without manual screen-clicking. Through Jentic, the agent searches by intent and Jentic returns the right Ninox endpoint with the bearer token attached server-side. File uploads stay scoped to the right record because the URL embeds the recordId and fileName.

Example prompt: Search Jentic for 'upload a file to a ninox record', load POST `/teams/{teamId}/databases/{databaseId}/tables/{tableId}/records/{recordId}/files/{fileName}`, and execute it for an invoice PDF.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/teams/{teamId}/databases/{databaseId}/tables/{tableId}/fields` | List the field schema for a table |
| GET | `/teams/{teamId}/databases/{databaseId}/tables/{tableId}/records` | List records in a table |
| POST | `/teams/{teamId}/databases/{databaseId}/tables/{tableId}/records` | Create a new record |
| PUT | `/teams/{teamId}/databases/{databaseId}/tables/{tableId}/records/{recordId}` | Update fields on a record |
| DELETE | `/teams/{teamId}/databases/{databaseId}/tables/{tableId}/records/{recordId}` | Delete a record |
| POST | `/teams/{teamId}/databases/{databaseId}/tables/{tableId}/records/{recordId}/files/{fileName}` | Upload a file attachment to a record |
| GET | `/teams/{teamId}/databases/{databaseId}/tables/{tableId}/records/{recordId}/files/{fileName}` | Download a file attachment from a record |

## Key resources

- **Teams** — List and inspect teams
- **Databases** — List and inspect databases inside a team
- **Tables** — List, inspect, and read schema fields of tables
- **Records** — List, create, read, update, and delete records
- **Files** — Upload and download attachments on records

## Why Jentic

- **Setup:** Wiring Ninox by hand means handling its bearer auth and threading team, database, and table ids through every path (https://api.ninox.com/v1) yourself. Through Jentic you install once, import the Ninox API from the API Directory, store the token once, and your agent calls it.
- **Permission scoping:** Ninox puts the team and database ids in the URL path (`/teams/{teamId}/databases/{databaseId}/...`), so a rule can pin your agent to one database: it can read table fields and create records for that database and nothing else. You choose the operations it may call, so destructive ones like deleting a record are not included unless you add them.
- **Credential handling:** Your Ninox token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'read a table's fields' or 'attach a file to a record', and Jentic returns the matching Ninox operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Ninox API** — The same Ninox API surface listed under the ninox.com domain - covers the core 9-endpoint records CRUD subset.
- **Airtable API** — Airtable is the most direct alternative low-code database with attachment support.
- **NocoDB API** — NocoDB is an open-source self-hostable low-code database with similar table-record CRUD.
- **Smartsheet API** — Smartsheet offers a spreadsheet-style database with attachment support.

## FAQ

### Which OpenAPI specification does this Ninox API page describe?

A curated, agent-optimized Jentic specification covering 14 Ninox operations across teams, databases, tables, records, and record file attachments. Ninox also publishes its own OpenAPI documentation at https://go.ninox.com/api/docs-json, titled Ninox Public API, which describes a different generation of the API built around workspace and module resources, carries 23 operations, and declares no server URL. The Jentic variant describes the teams-and-databases surface served under this listing's base URL, and Jentic keeps it validated and agent-ready. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Ninox API use?

Ninox uses HTTP bearer tokens. Issue a token from your Ninox account settings and send it as Authorization: Bearer <token>. Through Jentic, the token is held encrypted in the vault and attached server-side.

### Can I attach a file to a Ninox record?

Yes. POST `/teams/{teamId}/databases/{databaseId}/tables/{tableId}/records/{recordId}/files/{fileName}` uploads the binary attachment to the record. The matching GET endpoint downloads it back.

### What are the rate limits for the Ninox API?

Ninox enforces per-account rate limits but does not publish exact numbers in this spec. Bulk syncs should batch writes and back off on HTTP 429 responses.

### How do I update a Ninox record through Jentic?

Run pip install jentic, search Jentic for 'update a ninox record', and load PUT `/teams/{teamId}/databases/{databaseId}/tables/{tableId}/records/{recordId}.` Provide a fields object whose keys match the Ninox table column names.

### How is this spec different from the ninox.com Ninox API listing?

Both target the same api.ninox.com/v1 base URL. The ninoxdb.de spec exposes 14 endpoints - it adds GET routes for individual team/table inspection, table fields, and record file uploads/downloads, beyond the 9 covered by the ninox.com listing.

### Can I limit what my agent is allowed to do with the Ninox API?

Yes. Because you run Jentic One yourself, your own rules decide which Ninox operations and which token the agent may use. Since the team and database IDs sit in the URL path, a rule can pin the agent to a single database, letting it read table fields and create records there and nothing else. You choose the operations it may call, so a destructive route like DELETE on a record stays off unless you explicitly add it.