canonical: https://jentic.com/apis/extendsclass.com/extendsclass-json-storage

# Extendsclass JSON storage

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.

## For AI 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.

## Scope

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.

## Capabilities

- 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
- Delete a JSON bin by ID when it is no longer needed

## Use cases

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

Example prompt: 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.

Example prompt: 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.

Example prompt: 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.

Example prompt: 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.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/bin` | Create a new JSON bin |
| GET | `/bin/{id}` | Retrieve a bin by ID |
| PUT | `/bin/{id}` | Replace the contents of a bin |
| PATCH | `/bin/{id}` | Partially update a bin via JSON Merge Patch |
| DELETE | `/bin/{id}` | Delete a bin |

## Key resources

- **Bin** — A persisted JSON document addressed by ID

## Why Jentic

- **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 handling:** 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.
- **Discovery method:** 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.

## Related APIs

- **Filerobot DAM API** — Filerobot offers richer object and asset storage with auth and CDN delivery
- **Dropbox API v2** — Dropbox stores arbitrary files including JSON with full account-based access control
- **Box API** — Box adds enterprise-grade storage and governance for documents an agent later produces

## FAQ

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