Writing documentation

The Docs tab holds your API's README: the guide shown in the Documentation section of your public Overview page, right under the pricing summary. It's usually the first thing a developer reads.

Editing

Write in Markdown on the left; the right-hand side shows a live preview. Click Save when you're done. Everything Markdown supports works: headings, lists, links, tables, and code blocks with syntax highlighting.

What to include

A README that converts visitors into subscribers usually has:

1. Quick start: the gateway address and one copy-paste request that works:

   ```bash
   curl "https://your-api.p.apihiver.com/v1/example?q=test" \
     -H "X-API-Key: YOUR_API_KEY"
   ```

2. Endpoints: a table of every endpoint and what it does. Point readers to the Endpoints tab for full parameters and examples.

3. Authentication: remind readers to send X-API-Key. They never need a separate key from you.

4. Errors: the error format and codes your API returns, and what each means.

5. Limits: file size limits, timeouts, and anything expensive or slow.

6. Data & privacy: where your data comes from, and whether you store anything consumers send.

Tips

• Use real, working examples, and test them in the playground before you publish.
• Keep marketing copy in the listing description, and keep the README practical.
• Update the docs when you change an endpoint, and tell your subscribers with a message from Community (see Subscribers, analytics and revenue).