The Junction Order API orders lab tests and manages everything after the order: at-home phlebotomy, patient service center visits, test kits, tracking and results. Junction, formerly Vital, publishes 36 operations here across 34 paths. Only 3 of them accept an idempotency key.
Where the key is, and is not
| Operation | Idempotency key |
|---|---|
POST /v3/order Create Order |
Yes |
POST /v3/order/testkit Create Testkit Order |
Yes |
POST /v3/order/{order_id}/psc/appointment/book |
Yes, marked closed beta |
POST /v3/order/{order_id}/phlebotomy/appointment/book |
No |
POST /v3/order/import Import Order |
No |
POST /v3/order/{order_id}/cancel Cancel Order |
No |
Getting the first row right is the important part. A retried order creation is the expensive mistake, and an X-Idempotency-Error header accepts no-cache, which the service center booking describes as applying idempotency only to successful outcomes. That is a considered detail. The trouble is the second tier. A timed-out booking of a person coming to someone’s home has no declared key, while the equivalent booking at a service center has one in beta. An agent retrying the home visit has nothing in this contract to make the retry safe.
Twin names
The two appointment flows share a shape and, in five cases, a summary. “Book Phlebotomy Appointment” appears on both /phlebotomy/appointment/book and /psc/appointment/book. The same goes for reschedule, cancel, get, and the cancellation reasons list. A person sees the path. A tool generated from summaries sees two identical names for different real-world actions, one sending someone to a house and one booking a center. These summaries come from the provider’s definition, and the fix is small.
Other edges are visible too. POST /v3/order/{order_id}/test is an order simulator whose description reads “Get available test kits”, and the contract lists it on all four servers, production included. The API key header is still x-vital-api-key after the rename. The operations declare only 200, 422 and one 404, so nothing tells a caller what a replayed key or a rate limit returns.
What is good here
Plenty. There are separate US and EU servers with sandboxes for each, POST /v3/order/resend_events replays webhooks for a set of orders, and results come as a PDF, metadata and raw data from three separate calls. The page carries the OpenAPI, 7 JSON Schemas, 6 examples and 3 documentation links.
Provider-wide, Junction scores 73.2 (exemplar) on the Kin Score and 45.4 (agent-native) on Agent Readiness. Our agentic access record shows 197 operations and 45 acting, with 0 flagged human-in-the-loop. For an API that schedules blood draws, that zero deserves a look, on our side as much as theirs. Two pieces of our own text also need correcting: this page’s description says 32 operations when the list holds 36, and it still says Vital.
Takeaway
This is a serious healthcare contract with real sandbox and regional structure. Before pointing an agent at it, wrap the at-home booking and cancellation calls in your own retry guard, and disambiguate the five twin summaries in your tool definitions.
See the API at apis.io/apis/junction-com/junction-com-order-api/.