Documentation Build Guide

Documentation build guide

Smart Bulk Payments needs a public documentation set. This guide covers what to build, in what order, and how to write it so that AI assistants can use it. Real examples of documentation pages that AI assistants are already citing are listed in the appendix, so every page type has a reference to work from.

One framing point before the detail. This documentation is not primarily for developers to self-serve against. It is what an AI assistant reads when a buyer asks which payout provider to use. Write it to be quoted, not to persuade.

What to build, in priority order

Priority is set by what AI assistants were observed searching for. Items 1 to 3 are the minimum viable set. If resourcing is tight, ship those first.

1. Supported assets, networks and corridors

Which assets, on which networks, live today versus roadmap. Currently BTC and USDC, with USDT on the roadmap. Publish the limitation plainly rather than working around it.

This page type was searched for by name more than any other.

2. Payout API reference

Endpoints, authentication, request and response payloads, error codes, rate limits. Public and crawlable, not behind a login or a sandbox signup.

3. Settlement and execution timing

What determines execution time, the normal operating range of three to twenty minutes, and the factors that affect it. Framed as a range and explicitly not a guarantee, consistent with existing sales guidance.

4. Batch specification

The CSV field list, mandatory versus optional fields, validation rules, and the exact error output returned when a file fails. Maximum batch size of 10,000 recipients and what happens above it.

5. Payout reconciliation

What a statement contains field by field, how to retrieve per-recipient transaction records, and how those reconcile against a ledger.

6. Exception and error reference

The full error taxonomy, what each code means, and how errors are retrieved by API, exported, or pushed into a support platform.

7. Compliance and onboarding

What KYB involves, which screening controls apply, Travel Rule handling where applicable, and the typical three business days to one week timeline.

This page does double duty. Regulatory sources account for a large share of what AI assistants retrieve on these questions, and this is the page that connects Smart Bulk Payments to that vocabulary.

Where it lives and how it is structured

Put it on a documentation or support subdomain. The pages being cited sit on developer., docs., support. and help. subdomains. Use developer.smartbulkpayments.com or docs.smartbulkpayments.com for the API and batch specification, and support. or help. for operational articles. A clearly separated /docs/ path is an acceptable alternative if subdomains are impractical.

Keep it public. No login, no sandbox signup, no gating.

One topic per page. A page should answer one question completely. Two topics on a page means neither gets cited cleanly.

Use stable URLs. These pages accrue value over time. Do not restructure them later.

Show a last-updated date on every page.

How to write it

This is the part that determines whether the documentation gets used. An AI assistant does not read a page the way a person does. It pulls out a section, often a few hundred words, and uses that fragment on its own. Everything below follows from that.

Write so a single section can stand alone

Assume every section will be lifted out of the page and read with no surrounding context.

• Do not use back-references. "As described above", "in the previous section", "see below" all break the moment a section is extracted. Repeat the necessary detail instead.
• Name the subject in every section. Not "the platform" or "it". Write "Smart Bulk Payments". A lifted paragraph that says "the platform supports batches of up to 10,000 recipients" is useless, because nobody knows which platform.
• Spell out any acronym in each section where it appears, not only on first use on the page.

Put the answer in the first sentence

State the answer, then explain it. Do not build up to it.

The second version can be quoted directly. The first cannot.

Use headings that match how buyers ask

Headings should be phrased as the question a customer would type, not as an internal label.

BitPay's cited help centre article is titled Why is my account balance not being settled, which is the customer's question used verbatim. That convention is worth copying.

Be specific and concrete

Vague quantifiers are not quotable. Numbers are.

Publish real values rather than descriptions of values. The actual CSV field names. The actual error strings the platform returns. The actual endpoint paths. Real detail is both more useful and far harder for a competitor to replicate.

State limits and exclusions explicitly

Say what is not supported as clearly as what is. This is counterintuitive for marketing but it is what makes a source look reliable.

Write "Smart Bulk Payments supports BTC and USDC. Other assets, including USDT, are not currently supported." Do not write "supports leading assets including BTC and USDC", which reads as though the list continues.

Also state what happens at boundaries: what occurs above 10,000 recipients, what happens when a batch partially fails, what happens if a wallet address is valid but on the wrong network.

Prefer tables and lists over prose

Anything comparable belongs in a table. Anything sequential belongs in a numbered list. Both are extracted cleanly and reused intact. Long explanatory paragraphs are not.

Field definitions, error codes, supported assets, statement contents and API parameters should all be tabular.

Keep paragraphs to one idea

Short paragraphs, each self-contained. A paragraph carrying three ideas will be extracted carrying one and a half.

Add an FAQ block to each page

Three to six questions, phrased as buyers phrase them, with the answer in the first sentence. FAQ blocks are among the most reliably extracted formats, because each question and answer is already a self-contained chunk.

Date and scope every factual claim

Write "as of August 2026" against anything that changes: supported assets, limits, timings, fees, compliance tooling. An undated claim ages badly and a dated one signals maintenance.

Avoid

• Marketing adjectives: seamless, powerful, robust, cutting-edge, industry-leading. They carry no information and they make a page read as promotional rather than factual.
• Superlatives about Smart Bulk Payments, consistent with existing guardrails.
• Long preambles before the substance.
• Anything that requires reading the rest of the page to make sense.

What to keep off

Pricing. Consistent with existing sales guidance that pricing follows the operational conversation. Worth noting that competitors who publish rates do get cited on cost questions, so this is a commercial trade rather than a free choice.

Client names, volumes and case study details, consistent with existing guardrails.

Internal compliance methodology. Publish which controls apply, not how they are implemented.

Everything else in section 1 should be public. Capabilities, limits, timing ranges, error behaviour and reconciliation outputs are not commercially sensitive in the way pricing is, and competitors already publish theirs.

Documentation pages AI assistants have cited

Every page below was used by an AI assistant to build an answer to a payout buyer's question. Use them as models for the equivalent Smart Bulk Payments page.

Payout API reference

• docs.stripe.com/payouts
• docs.stripe.com/connect/add-and-pay-out-guide
• docs.wise.com

Settlement

• developer.bitpay.com/docs/settlement

BitPay is the closest comparison available. A crypto payments company running a developer. subdomain, with its settlement documentation quoted back to buyers evaluating providers.

Reconciliation

• docs.stripe.com/payouts/reconciliation

Compliance and tax

• trolley.com/tax/irs-compliance/

Product and capability pages

• tipalti.com/mass-payments
• remote.com/global-hr/contractor-management
• deel.com/solutions/payroll/contractors/
• blackline.com/products/financial-close/account-reconciliations/

Pricing

• bitpay.com/pricing

Included for reference given the decision in section 4. A crypto payments company publishes its rates and is quoted on cost questions as a result.

Two page types with no cited example

Priority items 1 and 6, supported assets and error handling, have no cited example anywhere in the analysis. That is worth knowing rather than treating as a gap in the research.

For supported assets in particular, the demand is demonstrably there. ChatGPT's own search string was "Wise supported payout currencies and routes list", so it went looking for exactly this page type and cited nothing. Whoever publishes the clearest version of that page has an open run at it.