B2B Integration

Definition

B2B integration connects your system to organisations you do not control, on timelines you do not control, using formats they may dictate. The distinguishing property is that you cannot upgrade the other side.

What that constraint implies

Versions live forever. A partner integrated in 2019 may never change. If the API cannot support that version indefinitely, the integration breaks and the commercial relationship suffers. This makes versioning strategy a commercial decision, not a technical preference.

Onboarding is the product. The time from signed contract to first successful transaction is a business metric. Self-service credentials, a sandbox with realistic data, and clear errors compress it; a manual process measured in weeks becomes a sales objection.

Support is a first-class cost. Partners will integrate incorrectly. Every ambiguity in the interface becomes support tickets forever, which is why documenting the failure model precisely is cheaper than answering questions about it.

Formats may not be yours. Established industries have standards — EDI in retail and logistics — that a partner will require. Translating at your boundary is usually cheaper than arguing.

Industry example

Delivery marketplaces integrate with tens of thousands of merchants running every conceivable point-of-sale system, from modern cloud APIs to a tablet in a kitchen. A DoorDash-style platform therefore cannot have one integration model; it needs a spectrum — a rich API for sophisticated partners, a middleware connector for common POS vendors, and a manual or tablet-based fallback for merchants with no system at all.

The architectural lesson is that the long tail is the design constraint. Optimising only for sophisticated partners excludes most of the market; optimising only for the tablet excludes the partners who drive volume. Supporting both means the integration layer must normalise wildly different capabilities into one internal model, and must be honest internally about which capabilities each partner actually has.

What good looks like

• Tiered integration options matched to partner sophistication.
• A sandbox that behaves like production, including failures.
• Explicit, long deprecation windows with proactive contact, not an email nobody reads.
• Per-partner observability, so you can answer "is it us or them" without a two-day investigation.
• Per-partner rate limits and isolation, so one partner's runaway job does not degrade others.
• Reconciliation, because partner systems will disagree with yours and someone must detect it.

Failure scenarios

• A breaking change shipped with a 30-day notice to partners whose change process takes six months.
• No per-partner isolation, so one integrator's retry loop degrades the platform.
• Ambiguity in the specification, producing a long tail of subtly wrong integrations that must each be supported.
• No sandbox, so partners test in production.

Interview question

"You must make a breaking change to an API used by 5,000 partners. What is your plan?"