Integration requirements template
A free template for scoping a third-party integration before it is built: systems, triggers, data mapping, failure handling — the doc that makes quotes comparable and syncs sane.
Most integration projects go sideways over the questions nobody wrote down: what triggers what, which system is the source of truth, what happens when the API fails. This template captures those answers before the build — it pairs with the integrations section, and sending it with your brief gets a sharper, faster quote. Copy it into a doc and fill what you know; "not sure" is a usable answer that names the real scoping question.
The fields, with guidance
Systems
The two (or more) systems to connect, with plans/tiers named — API access differs by plan more than vendors advertise.
Example: WooCommerce store (self-hosted) + QuickBooks Online Plus + Slack workspace.
Trigger events
What should cause what, as "when X happens in A, do Y in B". List every flow — the misses are what you discover in month two.
Example: When an order is paid → create invoice in QuickBooks and post to #sales in Slack.
Data mapping
Which field in A feeds which field in B, including formats (dates, currency, phone). The boring half that breaks first.
Example: WC order # → QB invoice no.; order total → subtotal line; GST → tax line; customer email → match-or-create.
Source of truth
For each shared entity (customer, order, stock), name the one system that wins on conflict. Syncs without this invent their own rules.
Example: Customer records: CRM wins. Stock counts: POS wins. Orders: store wins.
Failure handling
What should happen when the API is down, a field is missing, or a sync fails halfway — who hears about it, how fast, and what does the customer see?
Example: Failed sync → Slack alert + retry ×3, then email. Store never blocks on sync failure.
Volume & cadence
Records per day/week and how fresh data must be. Volume changes the architecture; cadence changes the cost.
Example: ~40 orders/day, need CRM records within 5 minutes; accounting sync daily is fine.
Access & accounts
Which accounts exist, who owns them, what API tiers they are on. Quote-blocker number one.
Example: Stripe account live (webhook access via developer); QuickBooks admin is our accountant.
Success test
The end-to-end check that proves it works — in one sentence, observable by you.
Example: Place a test order; invoice appears in QuickBooks and #sales pings within 5 minutes, refund reverses both.
Copy this block
INTEGRATION REQUIREMENTS
========================
SYSTEMS:
A:
B:
(plans/tiers + API access confirmed: yes/no)
TRIGGER FLOWS:
1. When [event] happens in A → [action] in B
2. ...
DATA MAPPING:
A.field → B.field (format notes)
SOURCE OF TRUTH:
Customers: A or B?
Orders/items: A or B?
Stock/status: A or B?
FAILURE HANDLING:
API down: (alert who / retry how / does the site block?)
Missing fields: (skip + log, or halt?)
Sync halfway: (rollback, resume, or manual list?)
VOLUME & FRESHNESS:
Records per day: ~
Max acceptable delay:
ACCESS:
Accounts that exist + owner + API tier confirmed
SUCCESS TEST (one sentence, observable):
...
BUDGET BAND:
TIMELINE:Plain text on purpose — pastes cleanly into email, docs and project tools.
Two notes from the field: first, the source-of-truth row is the one teams skip and regret — every duplicate record traces back to it. Second, the success test doubles as the acceptance criterion in the quote, which is what makes integration quotes comparable across developers. Ready to scope it? Send it with the brief — or browse the integrations section for what each kind of build includes.
Quarterly, and only when the numbers move
Get the rate report before you negotiate.
Updated rate bands across the major stacks and regions, plus what changed and why. No other email.