canonical: https://jentic.com/apis/gridfox.com/gridfox # Gridfox Public API Gridfox is a no-code app builder where each project is built around custom tables, fields, and reference relationships. The Public API exposes the runtime data layer of those apps - agents can create, read, update, and delete records in any user-defined table, list groups and permissions, manage users, fetch audit history, and upload files attached to records. Authentication is a single API key passed in the gridfox-api-key header. ## For AI agents Read and write records in custom Gridfox tables, manage users and permissions, and pull audit history from a no-code Gridfox project. ## Scope Does not handle project schema design, form rendering, or workflow automation - use for runtime data, file, user, and audit operations on existing Gridfox tables only. ## Capabilities - Create a record in a Gridfox table with POST `/data/{tableName}` - List records from a Gridfox table with GET `/data/{tableName}` - Update or delete a record by its reference field value - Upload, download, and delete file attachments on a record's field - Pull the audit history of a single record with GET `/data/{tableName}/{referenceFieldValue}/audit` - List all groups, permissions, and tables in the Gridfox project - Create, update, and delete users with the /users endpoints ## Use cases ### Sync External Data into Gridfox Push records from another system - a CRM, a webhook, a spreadsheet - into a Gridfox no-code app. Agents call POST `/data/{tableName}` to insert and PUT `/data/{tableName}/{referenceFieldValue}` to upsert by a stable reference field. This keeps a Gridfox dashboard in sync with operational systems without manual export. Example prompt: For each new lead in the source system, call POST `/data/Leads` with the mapped field payload, then verify with GET `/data/Leads/{referenceFieldValue}.` ### Audit and Compliance Reporting Generate an audit report for a record's full change history. The `/data/{tableName}/{referenceFieldValue}/audit` endpoint returns who changed what and when, which agents can compile into a compliance export. Useful for regulated workflows captured in Gridfox where change attribution must be retained. Example prompt: Call GET `/data/Contracts/{referenceFieldValue}/audit`, format the response as a CSV, and email it to the compliance distribution list. ### Attach Documents to Records Upload supporting documents directly onto a Gridfox record's file field. POST `/data/{tableName}/{referenceFieldValue}/{fieldName}` attaches the file, GET retrieves it, and DELETE removes it. This lets agents persist generated PDFs, contracts, or invoices alongside the record they relate to. Example prompt: Generate a PDF invoice, then call POST `/data/Invoices/{referenceFieldValue}/{fieldName}` to attach it to the matching invoice record. ### AI Agent No-Code Operator An ops assistant uses Gridfox as the team's source of truth for a workflow that doesn't justify a custom backend. The agent updates records, attaches files, and reads audit data through Jentic - no need for the agent author to learn Gridfox's bespoke schema, since Jentic returns the input shape on demand. Example prompt: Search Jentic for 'create a record in a Gridfox table', load the POST `/data/{tableName}` schema, and execute with the table name and field payload. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | `/data/{tableName}` | List records in a table | | POST | `/data/{tableName}` | Create a record | | GET | `/data/{tableName}/{referenceFieldValue}` | Get a record by reference | | PUT | `/data/{tableName}/{referenceFieldValue}` | Update a record | | DELETE | `/data/{tableName}/{referenceFieldValue}` | Delete a record | | GET | `/data/{tableName}/{referenceFieldValue}/audit` | Get the audit trail for a record | | POST | `/data/{tableName}/{referenceFieldValue}/{fieldName}` | Upload a file to a record field | | GET | `/tables` | List tables in the project | ## Key resources - **data** — Read and write records in any Gridfox table, including file attachments and audit history - **tables** — List the tables defined in the Gridfox project - **groups** — List groups configured in the project - **permissions** — List permissions assigned across the project - **users** — Create, update, and delete user records ## Why Jentic - **Setup:** Wiring the Gridfox Public API by hand means carrying its gridfox-api-key header and mapping the `/data/{tableName}` row, file, user, and audit endpoints yourself. Through Jentic you install once, import the Gridfox Public API from the API Directory, store the API key once, and your agent calls it. - **Permission scoping:** Gridfox puts the table name in the URL path (`/data/{tableName}`, `/data/{tableName}/{referenceFieldValue}`), so a rule can pin your agent to one table: it can read and list rows in that table and nothing else. You choose the operations it may call, so ones like deleting a row or removing a file are not included unless you add them. - **Credential handling:** Your Gridfox API key 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 rows from a Gridfox table' or 'get a record's audit history', and Jentic returns the matching Gridfox operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Airtable API** — Spreadsheet-database hybrid with a richer ecosystem - choose for broader integrations. - **NocoDB API** — Open-source no-code database that exposes a similar table API surface. - **Smartsheet API** — Sheet-style work management with strong audit and permissions. ## FAQ ### What authentication does the Gridfox Public API use? Gridfox accepts a single API key in the gridfox-api-key header (format: prefix.key). Through Jentic, the key is stored encrypted in your Jentic One instance and injected at call time so the raw key never enters the agent's context. ### Can I create records in any Gridfox table with the API? Yes. POST `/data/{tableName}` creates a record in any table the API key's user has permission to write. The field payload must match the table's schema - call GET /tables first if the agent does not know the field names. ### What are the rate limits for the Gridfox Public API? The OpenAPI spec does not publish explicit rate limits - Gridfox enforces them at the project level. Production agents should retry on 429 with backoff. Jentic surfaces the response so the agent can act on it. ### How do I audit changes to a specific record through Jentic? Search Jentic with 'get the audit history of a Gridfox record', load the GET `/data/{tableName}/{referenceFieldValue}/audit` schema, and execute with the table and reference value. The response lists each change with user, timestamp, and field deltas. ### Can I upload files to Gridfox records via the API? Yes. POST `/data/{tableName}/{referenceFieldValue}/{fieldName}` uploads a file to a record's file field, and the matching DELETE and GET endpoints remove or fetch it. File size limits are enforced by Gridfox at the project level. ### Does the API expose project schema? Partially. GET /tables lists the tables in the project but the field-level schema for each table is not in this spec. Agents typically learn the field names from a sample record retrieved via GET `/data/{tableName}.` ### Can I limit what my agent is allowed to do with the Gridfox Public API? Yes. Because Jentic One is self-hosted, your own rules decide which Gridfox operations your agent may call and which credentials it may use. Since Gridfox puts the table name in the URL path (for example `/data/{tableName}` and `/data/{tableName}/{referenceFieldValue}`), a rule can pin the agent to a single table so it only reads and lists rows there and nothing else. You choose the operations it can run, so destructive ones like deleting a record or removing a file attachment are excluded unless you explicitly allow them.