For coding agents

Most of the code written against this API is written next to an assistant. Every page here is therefore published twice: once as HTML for you, and once as plain text for whatever is reading over your shoulder. All of it is generated from the same pages, on every build, so none of it can fall behind what this site says.

The text exports

File	What it holds	Read it when
/llms.txt	The entry point: what this API is, the base URL, how to authenticate, and links to everything below	You want the smallest possible orientation
/llms-small.txt	Every page, abridged, with asides and collapsed sections removed	The whole API has to fit in one context window
/llms-full.txt	Every page, complete, including the compatibility matrix and the glossary	You want nothing left out
/_llms-txt/quickstart.txt	Getting started, creating a response, and errors	You need to make one call and handle what comes back
/openapi/v1.json	The /v1 contract as an OpenAPI 3.1 document	You are generating a client, or you want the exact shape of a field rather than a sentence about it

The pages come back in reading order rather than alphabetically: the quickstart and the two pages you need to send a request and read its reply come first, and what is not implemented comes last. A reader that runs out of room part way through still has the useful half.

Point a tool at the file directly:

curl https://docs.helping.io/llms-small.txt

The OpenAPI document

/openapi/v1.json is the whole /v1 surface as OpenAPI 3.1: every route, every request and response schema, and the bearer-token security scheme. The API reference is the same document rendered a page per operation, with curl and fetch snippets beside each one.

Neither is written by hand. The document is emitted from the same assembly the server mounts its router from, so it cannot describe a route the server does not serve, and the prose in it is the doc comments on the types themselves.

curl -o openapi.json https://docs.helping.io/openapi/v1.json

The skill

The same material is also published as a skill, so an agent that supports skills can carry it without being told to fetch a URL. It covers authenticating, the routes, the extension fields, streaming, the tool loop, and which error codes are worth retrying, with six reference files behind it:

File	What it holds
SKILL.md	The skill itself
references/errors.md	Every error code, its status and type, whether it carries Retry-After, and what it means
references/events.md	Every stream event and when it arrives
references/constants.md	The fixed timings and size limits
references/glossary.md	The name this platform uses for each thing
references/examples.md	Captured requests and responses to build a body against
references/openapi.json	The same OpenAPI document, carried with the skill so an agent does not have to fetch it
scripts/smoke.sh	Two curl calls that check a key reaches the API. Takes HELPINGIO_API_KEY from the environment; no key is stored in it

Installing it

The skill is not published to its marketplace repository, helpingio/skills, yet. The files themselves are live and linked above: copy SKILL.md and its references/ directory into your own skills directory in the meantime.

A snippet for your repository

For an assistant that reads a file at the root of your repository instead, /skill/AGENTS.md is the same guidance in a form you can paste in. /skill/cursor/helpingio.mdc is the same text as a Cursor rule, which belongs in .cursor/rules/.

AGENTS.md

curl -o AGENTS.md https://docs.helping.io/skill/AGENTS.md

Cursor

mkdir -p .cursor/rules
curl -o .cursor/rules/helpingio.mdc https://docs.helping.io/skill/cursor/helpingio.mdc

Both are short on purpose. They say what the API is, where it lives, how a request authenticates, that one request carries one turn, and that error handling branches on code. Anything longer belongs in the skill or in the text exports, which your assistant can fetch when it needs them.