Install Jentic One Beta

Connect the Gridfox Public API to your agent

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" | sh

Step 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 instance

Jentic 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.

Capabilities

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

GET STARTED

Start building with Gridfox Public API

Explore with Jentic One

View OpenAPI Document

Use Cases

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.

Key Endpoints

15 endpoints — gridfox is a no-code app builder where each project is built around custom tables, fields, and reference relationships.

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

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

Why Jentic?

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.

FAQs

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}.

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.

Gridfox Public API

Name: Gridfox Public API
Brand: Gridfox Public API
Availability: InStock

Official vendor OpenAPI document · agent-readyProductivityCollaborationapiKey15 EndpointsREST

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.

Jentic One on Github View OpenAPI Document

Connect the Gridfox Public API to your agent

Capabilities

Start building with Gridfox Public API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs

Gridfox Public API