Prefer a browser? The file uploader does the same thing without a terminal: drop a file, paste text, or paste a screenshot, and it hands you the shareable URL.
Store a JSON body
curl -X POST https://aisenseapi.com/services/v1/storage \
-H "Content-Type: application/json" \
-d '{"result":42,"status":"complete"}'{
"storage_id": "7bf4be7d-4386-49fd-99bb-6f2fe65f8a14",
"expire_timestamp": 1787266276,
"expire_datetime": "2026-08-20T22:51:16+00:00"
}The identifier above came from one real call and has since expired - yours differs on every request. Three fields come back. Keep the storage_id, because it is the only route back to the object. The service cannot look an ID up for you afterwards, and there is no listing call.
Retrieve the stored body
STORAGE_ID="the storage_id from the response above"
curl "https://aisenseapi.com/services/v1/storage/$STORAGE_ID"
{"result":42,"status":"complete"}That is the whole read path. No header, no token, no query string. An unknown or expired UUID answers with HTTP 404 and a short error object.
{"error":"Storage id unknown"}What the free storage API endpoint stores
The request body is stored verbatim. Nothing is wrapped around it and nothing is stripped from it. POST {"result":42} and the GET response is exactly {"result":42}.
Plain text behaves the same way. Send build 91 passed and those fifteen bytes come back untouched, served as application/octet-stream. Content that parses as JSON is served as application/json instead. One rule, two content types, no surprises.
That predictability is the point. Two programs that already agree on a format can pass data through this service without either side learning a new envelope.
Response fields
| Field | Type | Description |
|---|---|---|
| storage_id | string | The UUID used in the GET path. Treat it as the retrieval key. |
| expire_timestamp | integer | Unix time when the object disappears, 24 hours after the POST. |
| expire_datetime | string | The same moment as an ISO 8601 timestamp in UTC. |
How a hand-off works
- The producer posts
A job, script or agent sends its output to
/storageand receives a UUID in return. - The UUID travels
A UUID is small. It fits inside a webhook payload, a queue message, a database column or a chat reply, where a multi-megabyte body never would.
- The consumer reads
The next step calls
GET /storage/{storage_id}and receives the original bytes. Nothing needs to be shared between the two machines except that one string.
Where the PDF renderer puts its output
The HTML to PDF API endpoint is the clearest example of this pattern in use. It renders your markup, writes the finished PDF into storage and returns the storage ID rather than the file. You then download the document with a plain GET, at whatever moment suits you.
So the free storage API endpoint is worth understanding even if you never call POST yourself. It is already the delivery mechanism behind another service on this site.
Common uses
Most callers reach the free storage API endpoint from a pipeline rather than a browser. Four patterns come up again and again.
Agent hand-off
One agent stores a long result and passes a short UUID to the next.
Pipeline state
Move structured output between systems with no shared disk.
Oversized callbacks
Send a UUID in the callback and leave the payload here.
Reproducible bugs
Park a failing input so a colleague fetches the exact bytes.
Expiry and appropriate use
This is not a backup service. Objects become unavailable 24 hours after the POST, and there is no durability or service-level guarantee.
Anyone holding the UUID can read the object. Do not park secrets or regulated data here. Work that needs accounts, access policies or auditable deletion belongs in real storage.
The base URL is https://aisenseapi.com/services/v1. No key and no account are required. Every service on the free public REST APIs hub shares one limit of 5000 requests per IP per 24 hours, so a storage POST and a storage GET both count against the same budget.