River
Y CombinatorBacked by Y Combinator
FREE TEMPLATE

API Integration Guide Template

Four documents and two sheets that order your integration guide by the sequence sandbox logs show, not by your API's own resource list.

Free download  ·  No account needed

Integration Guide

[API name], [n] documented resources

Measured against [n] sandbox integrations that reached a first success event

The sequence, in four counts

Resources checked against their own first-touch order
Resources that tie with the documented order
Resources displaced from the documented order
Largest single displacement, in steps

The question a spec-generated guide never asks

Not what order the resources were added to the codebase in. What order sandbox logs show real integrations actually touching them in.

Confirmed against real tickets

Every displaced step cross-checked against the Common Error Register before the guide moves it, so a reorder is backed by a ticket count rather than a hunch.

Most developer-documentation advice agrees on one point: organize by the developer's journey, not by the product's own resource list. Mintlify's own navigation guide sets this out as a table, feature-centric against journey-centric, and recommends the second. GOV.UK's API documentation guidance goes further, building task-based sections from user research. Neither one measures the journey from what developers actually did. Both assume it: one from a generic template, the other from an interview.

This pack measures it instead. The worked example is Ledgerly Pay, an invented payments API with six documented resources. Checking 240 sandbox integrations that reached a first live charge against their own call order found two resources touched earlier than the spec documents. Payment Methods moved one step early. Webhooks moved three steps early, the largest single displacement of the six. The Integration Step Register records each resource's documented position, its measured position, and the gap between them, so a reorder ships with a number behind it, not a hunch.

The Common Error Register is the confirmation layer. Before the guide was reordered, those two displaced steps accounted for 163 of 312 support tickets in one quarter, 52.2 percent. One was an invoice failing with no default payment method. The other was a signature check failing on a genuine event because the secret was set too late. After reordering, the same two categories fell to 27 of 176 tickets in an equal-volume quarter, an 83.4 percent drop, while every other category held flat. Whether the reference still matches the product is the documentation audit.

Two of six resources displaced from their documented order account for 163 of 312 tickets, cut to 27 of 176 once the guide matched the measured sequence

The measured sequence, the Integration Step Register and the Common Error Register.

Measured Sequence

Ledgerly Pay, an invented payments API. Six documented resources, reordered against 240 sandbox integrations that reached a first live charge.

StepResourceDocumented positionDisplacement
1Customers10
2Payment Methods3+1
3Webhooks6+3
4Invoices2-2
5Payouts4-1
6Refunds5-1

Webhooks moves from documented position 6 to measured position 3, a 3-step displacement, the largest of the six and the reason it gets configured before Invoices in the guide rather than after Refunds.

Integration Step Register

Documented position taken from the OpenAPI spec's own tag order. Actual position is the median first-touch rank across the sample.

ResourceDoc pos.Actual pos.DisplacementSample
Customers110240
Invoices24-2240
Payment Methods32+1240
Payouts45-1240
Refunds56-1240
Webhooks63+3240

Total absolute displacement across all six resources is 8 steps; Webhooks alone accounts for 3 of those 8, 37.5 percent, from a single resource.

Common Error Register

Q1: guide still in documented order. Q2: guide reordered to the measured sequence. Same integration volume both quarters.

CategorySequence-dependentQ1 ticketsQ2 tickets
No default payment method at invoice creationYes748
Signature check failing on a genuine webhook eventYes8919
Malformed line items arrayNo5252
Rate limit during bulk importNo4141
Idempotency key reused on a changed payloadNo3434
API version header omittedNo2222
Total312176

The two sequence-dependent categories fall from 163 to 27 tickets, an 83.4 percent drop. Every other category holds exactly flat, confirming the reorder is what moved, not overall ticket volume.

What's in the pack

01

Integration Guide

Every documented resource, sequenced by measured first-touch order instead of the spec's own resource list, with the error each reordering avoids named.

02

Integration Step Register

Documented position against measured median position for every resource, with the displacement and the sample size stated plainly.

03

Common Error Register

Support-ticket categories mapped to the sequencing mistake that causes each one, with the ticket count before and after a reorder.

04

Authentication Walkthrough

The one path most integrations take first, plus what an auth failure actually looks like by error type, not just by status code.

05

Webhook Reference

Signature verification and retry behavior, the two things that generate almost every webhook-related support ticket.

06

Testing Guide

A pre-launch checklist ordered the same way the guide is, pulling its defensive tests straight from the error register.

07

A space rule every prompt reads first

A step's position comes from the call-log measurement, never from the spec's own tag order, and moves only when a ticket category confirms it.

How to use it

  1. 1

    Open it in River, or download it

    Open the pack and the agent measures your own sandbox logs before writing a single step, or download the blank guide and sheets.

  2. 2

    Send your spec and your call logs

    The API specification, sandbox call logs from integrations that reached a real success event, and a support ticket export if you have one.

  3. 3

    Rank each resource by measured first touch

    Every resource's documented position checked against its actual median position across the log sample, with the gap recorded rather than assumed.

  4. 4

    Confirm displacement against real tickets, then reorder

    Confirmed against a matching error category before it moves, the same way the tutorial and how-to pack checks a step's expected result.

Frequently asked questions

Is this template free?

Yes. Download the whole pack as Word documents and CSV sheets, no signup and no credit card. Edit with AI is a separate, optional path for anyone who wants the agent to measure their own call logs. Nothing happens until you send it a spec.

We don't have sandbox call logs yet. Can we still use this?

Yes, with a caveat stated on the register itself rather than hidden. Send the spec and name which steps you already suspect developers do out of order, and the guide gets built around that starting point, marked unmeasured until real log data can confirm or correct it.

How is this different from just writing task-based sections?

Task-based structure is the right instinct, and most documentation guidance already recommends it. What it doesn't do is tell you which tasks come first for your specific API. This pack answers that from your own sandbox logs instead of a generic assumed order like authenticate, then send a request, then handle errors.

Does the reorder change our API reference?

No. The reference generated from your OpenAPI spec stays exactly where it is and in whatever order it already renders. Only the guide, the walkthrough steps that tell a reader which order to read that reference in, gets reordered. A new API release is when the release notes pack becomes relevant instead.

How do you tell a real displacement from sampling noise?

By checking it against the Common Error Register before acting on it. A resource touched a step early or late in a small sample can be one unusual integration. A displacement that also matches a named, ticketed error category, at real volume, is the one worth reordering the guide around.

What format are the downloaded files?

Four Word documents and two CSV sheets, zipped. The documents open in Word, Pages and Google Docs; the sheets open in Excel, Numbers and Sheets. Add a PDF query string to the download if you want to circulate the guide rather than fill it in yourself.

How does this relate to the SME interview pack?

Different input. The SME interview pack is for when the facts you need live in an engineer's head and you have fifteen minutes to extract them. This pack's facts live in call logs and tickets you already have, so it measures rather than asks.

Find out which step your integration guide has in the wrong order

Download the blank Integration Guide, Step Register and Error Register as Word and CSV, or have River measure your own sandbox logs and tickets.

Edit with AI