For Agents
Read and write records in custom Gridfox tables, manage users and permissions, and pull audit history from a no-code Gridfox project.
Use for: Create a new record in the Customers table, List all records from the Orders table, Update the status field on order REF-1234, Upload an invoice PDF as an attachment to a record
Not supported: 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.
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.
Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Gridfox Public API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fgridfox.com%2Fgridfox" | shStep 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fgridfox.com%2Fgridfox" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
What an agent can do with Gridfox Public API.
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
Patterns agents use Gridfox Public API for, with concrete tasks.
★ 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.
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.
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.
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.
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.
15 endpoints — gridfox is a no-code app builder where each project is built around custom tables, fields, and reference relationships.
METHOD
PATH
DESCRIPTION
/data/{tableName}
List records in a table
/data/{tableName}
Create a record
/data/{tableName}/{referenceFieldValue}
Get a record by reference
/data/{tableName}/{referenceFieldValue}
Update a record
/data/{tableName}/{referenceFieldValue}
Delete a record
/data/{tableName}/{referenceFieldValue}/audit
Get the audit trail for a record
/data/{tableName}/{referenceFieldValue}/{fieldName}
Upload a file to a record field
/tables
List tables in the project
/data/{tableName}
List records in a table
/data/{tableName}
Create a record
/data/{tableName}/{referenceFieldValue}
Get a record by reference
/data/{tableName}/{referenceFieldValue}
Update a record
/data/{tableName}/{referenceFieldValue}
Delete a record
/data/{tableName}/{referenceFieldValue}/audit
Get the audit trail for a record
/data/{tableName}/{referenceFieldValue}/{fieldName}
Upload a file to a record field
/tables
List tables in the project
What agents get from Jentic-routed access to this vendor.
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 isolation
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.
Intent-based discovery
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.
Alternatives and complements available in the Jentic catalogue.
Specific to using Gridfox Public API through Jentic.
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}.
GET STARTED