Most integration projects fail on assumptions, not on code. A developer reads a vendor’s documentation, sees a sensible order payload, and builds against what the docs imply rather than what the system actually does. Six weeks later the reconciliation job finds gaps nobody expected.
These are the questions worth asking before a line of code gets written. They come from what technical teams actually ask, not from a template.
What identifier comes back to me?
You need something you can join on. If you send your own order reference, does it come back on the fulfillment callback? If the order arrived through a storefront or a shipping platform rather than through the API directly, does the callback carry the platform’s order number instead? Get this in writing before you build, because a callback you cannot join to your own record is a callback you have to reconcile by hand.
Does order creation dedupe, and on what field?
Payment processors redeliver webhooks. Retry logic fires twice. You will submit the same order more than once, and it will not be your fault. Ask whether the endpoint supports an idempotency key, or whether it upserts on your order reference. If a vendor describes an endpoint as an upsert, ask specifically which field determines whether an order is new.
Is there a read path, or is delivery push only?
Webhooks get dropped. If the only way you learn about fulfillment is a push you might miss, you have no way to recover. Ask whether you can look up a single order, and whether you can list orders changed since a timestamp. Nightly reconciliation depends on the second one.
What do the statuses actually mean?
Complete is the most overloaded word in fulfillment. It can mean the shipment left the building, or it can mean the tracking number and unit identifiers now exist and are available to read. Those are different moments and they can be hours apart. Ask what each status signifies in physical terms.
If a webhook fires more than once, does the payload change?
A status driven webhook that fires at pending and again at complete may deliver a different shape each time, with tracking numbers absent on the first. Build for that or your parser breaks on the first order.
What identity does each individual kit carry?
For a regulated program this is the question that matters most. Does every unit have its own identifier, or is identity assigned at the order level? On a multi unit order, do you get all of them back? Is that identifier the same one the receiving laboratory will use, or does the laboratory generate its own accession number, and if so can you get the mapping?
Without that mapping, tracing a result back to a specific unit becomes a manual exercise, and it stops being possible at all once volume rises.
When is the identifier assigned?
There is a real difference between an identifier created during production and an identifier bound to an order at fulfillment. If your workflow needs a unit associated with a specific recipient before it ships, say so at scoping. That is a different build from assigning at pack out, and discovering it late is expensive.
Is there return tracking, and is it per unit?
Any program with a specimen coming back needs the inbound label tied to the same identifier as the outbound unit. Ask whether return tracking is returned at the parcel level or the individual unit level. For a multi unit shipment those are not the same thing.
What happens when something goes wrong?
Ask about failure callbacks for a bad address, an out of stock component, or damage found at pack out. Then ask separately about shipments returned undelivered, which is a different event and is often not built. Also ask whether there is a cancel endpoint, and more importantly what the operational cutoff is: the point in pick, label, and manifest after which an order physically cannot be stopped. That cutoff is an operations answer, not a software answer, and a vendor who cannot tell you probably has not thought about it.
Is there a sandbox?
Ask whether there is a staging environment with its own credentials, or whether you are expected to test against production with a test SKU. Both are workable. Only one of them is safe to find out about after launch.
Can I see stock on hand?
If you sell what you do not have, you find out at fulfillment. An endpoint for current stock per SKU turns that into something you can prevent.
The answer that should reassure you
Ask a vendor a list like this and you will get one of three replies.
Some say yes to everything. That is the worst outcome, because you will build against promises and discover the gaps during launch week.
Some go quiet. Also bad, for obvious reasons.
The answer you want separates what exists today from what is technically possible from what is a new build with its own timeline. A partner who tells you that feasible means their developer sees no technical obstacle, that it does not mean the thing exists today, and that anything not already running gets its scope and timing agreed before anyone commits, is a partner whose yes means something.
That distinction is worth more than any single feature on the list above.
Two things specific to regulated programs
Everything here applies to any fulfillment integration. Two things apply only to yours.
The first is that unit level identity is not a convenience. In a program where a specimen comes back to a laboratory, the chain from order to unit to return label to accession is the record. If any link in it is manual, it will break, and it will break at the worst possible volume.
The second is that the data traveling with the order matters as much as the order. Requisition detail, provider information, panel selection, lot requirements. If your provider can only accept an address and a SKU, that information arrives by email afterward and someone reconciles it by hand.
Related reading: fulfillment API and ecommerce integrations covers the order payload, the fulfillment webhook, and how kit level identifiers are returned.
