For developers and agents

The StudioChat content API

Everything published on studiochat.io is readable three ways: as HTML, as markdown, and as JSON through the API below. No key, no OAuth, and nothing here writes. This page is the contract.

Start here

One request describes the whole API: the endpoints that exist, where the OpenAPI document is, and what the current rate limit is.

curl https://studiochat.io/api/v1

Endpoints

GET	/api/v1	What the API offers, plus the live rate limit and versioning policy.
GET	/api/v1/pages	Every indexed page, as a directory of URLs. Cheap: it carries links, not text.
GET	/api/v1/pages/{path}	One page, with its full text as markdown. Use `index` for the homepage.
GET	/api/v1/posts	Published blog posts, newest first. Narrow with `?tag=`.
GET	/api/v1/posts/{slug}	One post, with its body and its FAQ.
POST	/api/v1/batch	Up to 20 reads in a single request.
GET	/openapi.json	The OpenAPI 3.1 description of everything above.

curl "https://studiochat.io/api/v1/pages/ecommerce?locale=es"
curl "https://studiochat.io/api/v1/posts?tag=soporte&limit=5"

Languages

Every endpoint takes `?locale=en|es|pt`, and English is the default. A blog post with no translation yet resolves to another language: the response reports the locale it actually resolved to and which ones exist, so a fallback is never presented as a translation.

Pagination

Lists are cursor based. Read `pagination.nextCursor` and send it back as `?cursor=`. Treat the cursor as a token to echo, not a value to construct. `limit` defaults to 25 and caps at 100.

Batch reads

An agent assembling an answer usually wants several pages at once, and looping one call at a time is what makes an API expensive to use. POST an `operations` array and get one result per operation, each with its own status, so a single failure does not sink the rest. A batch counts as one request against the rate limit and takes at most 20 operations.

curl -X POST https://studiochat.io/api/v1/batch \
  -H "Content-Type: application/json" \
  -d '{"operations":[
        {"id":"home","resource":"page","path":"/"},
        {"id":"fin","resource":"page","path":"/fintech","locale":"es"}
      ]}'

Errors

Every failure is an RFC 9457 problem document served as `application/problem+json`, with a stable `code` to branch on and a `resolution` naming the next step. Branch on the code, not on the message.

invalid_request400: A parameter is wrong. `detail` names which one.
resource_not_found404: No page or post exists at that path or slug.
method_not_allowed405: Use GET. Only /api/v1/batch accepts POST.
rate_limit_exceeded429: Wait the number of seconds in `Retry-After`, then retry.
content_unavailable502: The page exists and we failed to read it. Retry, or read the HTML or markdown instead.

Rate limits

120 requests per 60 seconds, per client IP. Every response carries the IETF `RateLimit-Policy` and `RateLimit` structured fields plus the older `X-RateLimit-*` trio, and a 429 adds `Retry-After`. Read them and throttle from the real numbers rather than guessing.

RateLimit-Policy: "content";q=120;w=60
RateLimit: "content";r=118;t=47

Versioning and deprecation

The major version lives in the path, starting at `/api/v1`. Fields may be added within v1 without notice, so ignore what you do not recognise. A breaking change gets a new major path, signalled with RFC 9745 `Deprecation` and `Link` headers, and a dated `Sunset` header at least 90 days before anything is removed.

Questions

Write to hey@studiochat.io and a person answers.