For Agents
Persist arbitrary JSON documents to an ExtendsClass bin and read, update, patch, or delete them by ID - useful as scratch storage for prototypes and agent state.
Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the JSON storage, 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%2Fextendsclass.com%2Fextendsclass-json-storage" | 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%2Fextendsclass.com%2Fextendsclass-json-storage" | 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 JSON storage API.
Create a new JSON bin and receive its generated ID for later access
Retrieve the JSON body of a bin by its ID
Replace the JSON body of an existing bin with a PUT update
Apply a JSON Merge Patch to an existing bin without overwriting unrelated keys
GET STARTED
Use for: Create a JSON bin to stash this configuration object, Retrieve the JSON document stored in bin abc123, Replace the contents of an existing bin with a new payload, Patch a single field inside a JSON bin without touching the rest
Not supported: Does not handle file uploads, schema validation, queryable databases, or access control - use for storing, reading, patching, and deleting JSON documents addressed by ID only.
ExtendsClass JSON Storage is a lightweight cloud storage API for JSON documents - sometimes called "JSON bins." It exposes five endpoints to create, read, update (PUT or JSON Merge Patch), and delete bins keyed by ID. The API is intentionally minimal: no accounts or auth headers in this spec, no schema validation, just persisted JSON bodies addressed by /bin/{id}. It is suited to prototyping, mock APIs, and small agent state stores rather than production data persistence.
Delete a JSON bin by ID when it is no longer needed
Patterns agents use JSON storage API for, with concrete tasks.
★ Mock API for Prototyping
Create a JSON bin via POST /bin and use the generated ID's GET /bin/{id} as a stand-in API endpoint for a frontend or agent prototype. The same bin can be edited with PUT or PATCH as the prototype evolves. This avoids spinning up a backend just to return canned JSON during early development.
Call POST /bin with a JSON body representing a mock product catalogue, capture the returned bin ID, and use GET /bin/{id} as the prototype's data source.
Lightweight Agent State Store
An agent that needs to persist a small piece of state across runs can store it in a bin via POST /bin and update it with PUT /bin/{id} or PATCH /bin/{id}. The PATCH endpoint accepts JSON Merge Patch, so the agent can update one field at a time without re-sending the whole document. Suitable for low-stakes scratch state, not for sensitive data.
Call PATCH /bin/{id} with {"last_run": "2026-06-10T12:00:00Z"} to update only the agent's last-run timestamp.
Configuration Snapshot Sharing
Stash a configuration JSON in a bin and share the bin URL with collaborators or downstream agents who can fetch it via GET /bin/{id}. Updates can be applied with PUT /bin/{id} and the consumers re-fetch on a schedule. This is convenient for one-off sharing where no auth or versioning is required.
Call PUT /bin/{id} with an updated configuration JSON and notify downstream consumers that the bin URL now returns the new version.
AI Scratch Storage via Jentic
An AI agent uses Jentic to call ExtendsClass JSON Storage operations as scratch storage during a multi-step workflow - for example, persisting an intermediate report and reading it back from another step. The bin ID stays in the agent's working memory while the JSON body lives in ExtendsClass.
Through Jentic, search 'create a json bin', load POST /bin, execute it with the intermediate state, and pass the returned ID to the next step.
5 endpoints — extendsclass json storage is a lightweight cloud storage api for json documents - sometimes called "json bins.
METHOD
PATH
DESCRIPTION
/bin
Create a new JSON bin
/bin/{id}
Retrieve a bin by ID
/bin/{id}
Replace the contents of a bin
/bin/{id}
Partially update a bin via JSON Merge Patch
/bin/{id}
Delete a bin
/bin
Create a new JSON bin
/bin/{id}
Retrieve a bin by ID
/bin/{id}
Replace the contents of a bin
/bin/{id}
Partially update a bin via JSON Merge Patch
/bin/{id}
Delete a bin
What agents get from Jentic-routed access to this vendor.
Setup
Wiring the ExtendsClass JSON storage API by hand still means tracking the /bin paths and choosing the right verb for each change yourself, even though the spec declares no auth. Through Jentic you install once, import JSON storage from the API Directory, and your agent calls it through the same execution layer as any other API.
Permission scoping
JSON storage puts the bin id in the URL path (/bin/{id}), so a rule can pin your agent to one bin. You choose the operations it may call, so a DELETE on that bin is not included unless you add it alongside the read and patch operations.
Credential isolation
This spec declares no auth, so there is no credential to store, and the call still runs through your own Jentic One instance. If you use a paid tier with bin secrets, those are stored once, encrypted, and injected at execution time without entering the agent's prompt, logs, or context.
Intent-based discovery
Agents search Jentic by intent such as 'create a json bin' or 'update a json bin', and Jentic returns the matching JSON storage operation with its input schema so the agent picks the right verb on /bin or /bin/{id} without browsing the reference docs.
Alternatives and complements available in the Jentic catalogue.
Specific to using JSON storage API through Jentic.
What authentication does the JSON storage API use?
This OpenAPI spec declares no security scheme - the documented endpoints are accessed without an Authorization header. ExtendsClass may apply per-IP throttling and offers paid plans with optional bin secrets; check the live extendsclass.com/json-storage docs for current behaviour. Through Jentic, no credentials are needed for these operations.
Can I update only one field of a JSON bin?
Yes. PATCH /bin/{id} applies a JSON Merge Patch (RFC 7396), so sending {"status": "done"} updates only the status key while leaving every other field in the document untouched. Use PUT /bin/{id} when you want to replace the whole document.
How do I create a new bin and use it as a mock endpoint?
Call POST /bin with the JSON body you want to serve. The response includes the bin's ID, and GET /bin/{id} will then return that JSON. Combine with a frontend fetch call to use the bin as a quick mock endpoint during prototyping.
Is this API suitable for production data?
No. JSON storage is designed for prototypes, mocks, and lightweight scratch storage. There is no schema enforcement, no per-record encryption guarantees from this spec, and no versioning. Use a managed database for production workloads.
How do I store an agent's intermediate state through Jentic?
Run pip install jentic, then search 'create a json bin', load POST /bin, and execute it with the agent's state object. Capture the returned bin ID and use GET /bin/{id} or PATCH /bin/{id} on subsequent steps to read or update the state.
What are the rate limits for ExtendsClass JSON storage?
Rate limits are not published in this spec. ExtendsClass applies per-IP and per-plan throttling on the live service; treat 429 responses as authoritative and back off using any Retry-After header that is returned.
Can I limit what my agent is allowed to do with the ExtendsClass JSON Storage API?
Yes. You run Jentic One yourself, so your own rules decide which JSON Storage operations the agent may call and which credentials it may use. Because the bin id sits in the URL path (/bin/{id}), a rule can pin the agent to a single bin, and you choose the verbs it gets, so it can read (GET) and patch (PATCH) that bin without ever being handed DELETE unless you explicitly add it. Any operation you leave out simply is not available to the agent at execution time.