For integration engineers and the teams who inherit them
A retried call with no idempotency key writes the record twice. A delivery with no replay is lost when your endpoint is down for ten minutes. A sandbox with different limits from production is a rehearsal for a different play. This page specifies the failure semantics, because those are what you will actually be maintaining.
Every platform has an endpoint list, and the endpoint list is the least useful part of an evaluation. What determines the next five years is a set of properties that are rarely written down anywhere: what happens when a call times out but succeeded, what happens when a delivery arrives twice, what happens when your receiver was down for ten minutes, and whether the limits you developed against are the limits you will meet.
Duplicates are the classic and they are almost always self-inflicted by the retry that seemed responsible. A call times out on the network after the far side already committed it, the client retries, and now there are two. The fix is an idempotency key that the server honours, and whether one exists is a question you have to ask specifically because a capability list will never mention it.
Deliveries are the other half. A push to your endpoint is only as good as what happens when your endpoint is unavailable, and the honest answers range from a bounded retry with replay available afterwards to a single attempt and silence. Teams frequently discover which one they bought during a deployment window when their receiver was down for eleven minutes.
The sandbox is the quiet betrayal. It has different rate limits, a smaller dataset, no latency and none of the concurrency, so an integration built against it behaves differently the first time it meets real volume. Everybody knows this and hardly anybody asks for the differences to be written down.
And underneath all of it is versioning. An endpoint changes shape, a field becomes optional, an enumeration gains a value nobody expected, and the failure is not an error — it is a silently different behaviour in a job that runs at two in the morning and is noticed a week later in a report.
An integration is specified by its behaviour under failure rather than by its endpoints — and idempotency, retry, replay, ordering and sandbox fidelity are almost never in a capability list, so they are agreed by accident and discovered in production.
Idempotency first, because it prevents the most common damage. Every write accepts a key you supply, and a repeat of the same key returns the original result rather than performing the work again. That means your retry logic can be as aggressive as your reliability requires without your reliability creating duplicates, which is the trade every integration team ends up making badly in the absence of a key.
Deliveries to your endpoint are retried on a bounded schedule with a stated maximum, and everything is replayable afterwards by time range. That combination matters more than the retry schedule alone: a bounded retry protects you from a brief unavailability, and replay protects you from a long one. A surface with retries and no replay converts a maintenance window into permanent data loss.
Ordering is stated rather than assumed, because assuming it is the subtler failure. Deliveries carry a sequence within a subject so a receiver can detect a gap or an out-of-order arrival rather than silently applying the older state last. Nothing here promises global ordering, because a system that promised it would be lying or would be slow.
Limits are documented in advance and the sandbox enforces the same ones. A sandbox that is more permissive than production is a rehearsal for a different play, and a team that only discovers the real limit under real volume discovers it during their launch.
On versioning, the commitment is that a version behaves the same way for as long as it exists: fields are added rather than repurposed, enumerations grow rather than change meaning, and a breaking change is a new version rather than a Tuesday. Deprecation, notice periods and the pinning mechanism are the subject of their own page because they are a discipline rather than a property of the surface.
Whether a repeated write duplicates — measured by sending the same idempotency key twice and confirming one result rather than two.
What happens when your receiver is down — measured by stopping your endpoint for ten minutes and confirming the deliveries retry and replay.
Whether a gap is detectable — measured by inspecting the sequence on deliveries and confirming a dropped one is visible to your receiver.
Whether the sandbox tells the truth — measured by comparing documented limits, latency and concurrency between sandbox and production.
Whether a limit is documented before you meet it — measured by the published limit table, checked against what a load test actually encounters.
Whether a version can change under you — measured by the written commitment that a version’s shape only grows, plus the pinning mechanism.
no global ordering guarantee across subjects, because a system promising one would either be lying or be unusably slow. No claim that a sandbox reproduces production performance — it reproduces limits and semantics, not throughput. No claim that every third-party connector behaves identically, because their failure semantics are theirs. An independent SOC 2 Type II attestation is in progress and no report exists yet.
The surface is the same one every part of the product uses, which is the property that keeps it honest. A separate integration surface built beside a richer internal one is the arrangement where an endpoint you depend on quietly falls behind, and the divergence is invisible until you need something the internal path already has.
Credentials are yours and revocable by you, so an integration can be stopped from your side without a conversation. That matters during an incident on either side, and it is the only form of control that reliably works in the week somebody is worried.
Where you would otherwise build a synchronisation job, look first at whether a delivery already carries what you need. A team that polls because nobody told them a delivery existed has built a thing they will maintain for years, and that is the most common avoidable cost in this whole area.
Every claim on this page is testable in a sandbox in under a day, which is unusual and is the point. Send a duplicate key. Stop your receiver. Drop a delivery and look for the gap. Push at the limit. None of those requires our cooperation and each of them settles a question that a capability list cannot.
The properties are designed rather than independently attested, as everywhere else here. For an integration surface that matters less than usual, because the tests above exercise the behaviour directly rather than relying on a description of it.
What is deliberately not promised is global ordering across subjects. A surface that promised it would be making a claim that either fails under concurrency or is bought with latency nobody wants, and the honest arrangement is a per-subject sequence that lets your receiver detect what it needs to detect.
A SOC 2 Type II attestation is in progress and no report exists yet; it is an attestation with a defined scope and period rather than a certification.
Send the same idempotency key twice and confirm you get one result. This is thirty seconds and it prevents the single most common integration defect in production.
Take your receiver down for ten minutes deliberately and watch what arrives afterwards. The behaviour you observe is what your maintenance windows will cost you for the life of the integration.
Compare the sandbox limits against the production limits in writing. If nobody can produce that comparison, assume they differ and design for the stricter case you have not seen.
And ask for the versioning commitment in writing before the design is fixed, because a surface whose shape can change under a pinned version makes every one of the tests above a snapshot rather than a property.
Sandbox access for your integration engineer to run the duplicate-key, receiver-down, dropped-delivery, limit and version tests before any integration design is agreed.
Those five tests take a day and they determine the shape of everything built afterwards. An architecture drawn before them is drawn against assumptions, and the assumptions that turn out wrong are expensive precisely because the architecture was already agreed.
Run them as your own engineer rather than as a demonstration. A behaviour somebody shows you is a behaviour under conditions they chose; a behaviour you provoke is the one you will meet.
Then fix the design, with the limits and the failure semantics written into it rather than discovered by it.
Nothing about the endpoint list, and that is the point — the endpoint list is the least useful part of the evaluation. What differs between surfaces is the behaviour under failure: whether a write accepts an idempotency key so your retries cannot duplicate, whether a delivery to a down receiver is replayable afterwards or simply gone, whether a gap is detectable, and whether the sandbox enforces the same limits. Those five decide what the integration costs to own, and none of them appears in a capability comparison.
They usually do, and the cause is almost always a responsible retry rather than a careless one — a call times out on the network after the far side already committed, the client retries correctly, and there are now two. The only real fix is a server that honours an idempotency key you supply, so a repeat returns the original result rather than performing the work again. Test it in thirty seconds: send the same key twice and count the results. Ask every supplier the same question, because the ones without a key will tell you to retry carefully instead.
They retry on a bounded schedule, and anything that still did not land is replayable afterwards by time range. That pairing is what matters — retries alone cover a brief blip, and replay is what covers a deployment window or an outage on your side. A surface with retries and no replay quietly converts every maintenance window into permanent missing data, and that is usually discovered a week later from a report rather than at the time.
Not globally, and a supplier who says yes is either mistaken or is buying it with latency you would not accept. What is provided is a sequence within each subject, so your receiver can detect a gap or an out-of-order arrival and decide what to do rather than silently applying an older state last — which is the failure that actually causes damage. Design for detection rather than for a promise, because the promise is the thing that breaks under exactly the concurrency you built the integration to handle.
It usually does not, which is why the commitment here is specifically about limits and semantics rather than about performance. The sandbox enforces the same rate limits and the same failure behaviour; it does not reproduce production throughput and nobody should claim it does. Ask every supplier for a written comparison of the two, and where nobody can produce one, design against the stricter case you have not seen — a sandbox more permissive than production is a rehearsal for a different play and you find that out during your launch.