The API Reference is the foundation of your API documentation. It’s a comprehensive, exhaustive listing of every endpoint, parameter, and response field. While guides show users how to accomplish tasks, the reference tells them exactly what’s possible.
All users will eventually need the reference documentation to make full use of your API. This is where accuracy and completeness matter most.
How should you organize your reference entries?Choose an organization scheme that matches how users think about your API:
By Resource
By Function
Alphabetically
Group endpoints by the resource they operate on:
## Payments- POST /payments- GET /payments/:id- PATCH /payments/:id- DELETE /payments/:id## Customers- POST /customers- GET /customers/:id- LIST /customers
Show the exact method and endpoint path.Make it immediately clear what request to make.
## Create a Payment```httpPOST https://api.example.com/v1/payments```Creates a new payment transaction.
For paths with variables:
## Retrieve a Payment```httpGET https://api.example.com/v1/payments/{payment_id}```Retrieves the details of a payment that has been previously created.
Complete Parameter Documentation
Document every parameter exhaustively.
The #1 rule of reference documentation: document ALL parameters. Missing parameters make the API impossible to use fully.
For each parameter, include:
Property
Required
Description
Name
Yes
The exact parameter name
Type
Yes
Data type (string, integer, boolean, object, array)
Required/Optional
Yes
Whether the parameter must be included
Description
Yes
What it does and when to use it
Valid values
If limited
Enum values or acceptable range
Default value
If applicable
What happens when omitted
Example
Recommended
Sample value
### Parameters<ParamField path="amount" type="integer" required> Payment amount in the smallest currency unit (e.g., cents for USD). Must be a positive integer. Minimum: `50` ($0.50) Maximum: `99999999` ($999,999.99)</ParamField><ParamField path="currency" type="string" required> Three-letter ISO currency code in lowercase. Supported currencies: `usd`, `eur`, `gbp`, `jpy`, [see full list](/docs/currencies)</ParamField><ParamField path="capture_method" type="string" default="automatic"> When to capture the payment. - `automatic` - Capture immediately (default) - `manual` - Authorize now, capture later Use `manual` for pre-authorization or delayed capture workflows.</ParamField><ParamField path="metadata" type="object"> Set of key-value pairs for storing additional information. Maximum 50 keys, each key up to 40 characters, each value up to 500 characters. ```json { "order_id": "12345", "customer_name": "Jane Doe" } ```</ParamField>
Request Examples
Provide working, copy-pasteable examples.Show both the URL syntax and a complete request example.
Show examples in multiple languages if you support multiple SDKs.
Response Documentation
Document the response structure completely.Explain every property that can appear in the response:
## ResponseReturns a Payment object if successful.<ResponseField name="id" type="string"> Unique identifier for the payment. Format: `pay_` followed by 24 alphanumeric characters</ResponseField><ResponseField name="status" type="string"> Current payment status. Possible values: - `pending` - Payment is being processed - `succeeded` - Payment completed successfully - `failed` - Payment failed (see `error` field) - `canceled` - Payment was canceled</ResponseField><ResponseField name="amount" type="integer"> Amount charged in the smallest currency unit.</ResponseField><ResponseField name="created" type="timestamp"> Unix timestamp when the payment was created.</ResponseField><ResponseField name="metadata" type="object" optional> Additional information attached to the payment. Only present if metadata was provided in the request.</ResponseField>### Example Response```json{ "id": "pay_1A2B3C4D5E6F7G8H", "object": "payment", "status": "succeeded", "amount": 2000, "currency": "usd", "created": 1640000000, "payment_method": "pm_card_visa", "description": "Order #12345"}```
Clearly indicate which fields are always present vs. conditionally returned.
Error Documentation
Explain what can go wrong.Document common error responses:
## Errors<ResponseField name="error" type="object"> Present when the request fails.</ResponseField>### Common Errors| Status | Error Code | Description ||--------|------------|-------------|| 400 | `invalid_request` | Missing required parameter or invalid value || 401 | `invalid_api_key` | Authentication failed - check your API key || 402 | `card_declined` | The card was declined by the issuer || 404 | `resource_not_found` | The payment ID doesn't exist || 429 | `rate_limit_exceeded` | Too many requests - slow down || 500 | `internal_error` | Something went wrong on our end |### Example Error Response```json{ "error": { "type": "card_error", "code": "card_declined", "message": "Your card was declined.", "param": "payment_method" }}```
## Real-World Examples<CardGroup cols={2}> <Card title="Google Gmail API" icon="google" href="https://developers.google.com/gmail/api/v1/reference"> Comprehensive reference with consistent structure, clear parameter documentation, and organized by resource </Card> <Card title="Stripe API" icon="stripe" href="https://stripe.com/docs/api"> Gold standard for API reference docs - complete, searchable, with live examples and multiple languages </Card></CardGroup>## Common Mistakes to Avoid<Warning>Avoid these common reference documentation pitfalls:</Warning>- **Missing parameters** - Users will discover them anyway, often the hard way- **Vague descriptions** - "User ID" is not enough; explain what it's for and where to get it- **No examples** - Abstract schemas are hard to understand without concrete examples- **Ignoring edge cases** - Document what happens with null values, empty arrays, etc.- **Inconsistent organization** - Switching between alphabetical and functional organization is confusing- **Outdated examples** - Code that doesn't work destroys trust- **No error documentation** - Users need to handle errors gracefully<Info>The reference is often the most-visited part of your documentation. Users bookmark specific endpoints and return frequently. Make it comprehensive and easy to navigate.</Info>## Next Steps<CardGroup cols={2}> <Card title="Overview Template" icon="map" href="/templates/overview"> Provide context about what your API does </Card> <Card title="Quickstart Template" icon="rocket" href="/templates/quickstart"> Get users to their first successful API call </Card> <Card title="Setup Template" icon="gear" href="/templates/setup"> Authentication and environment configuration </Card></CardGroup>