ApparelMagic said 200. Nothing happened.
The status code tells you the request arrived. It does not tell you the work was done.
One retailer's pick-up-in-store orders arrive by EDI. Each morning, ten minutes before the label run, a small job takes each one through ApparelMagic: check stock, approve credit, allocate, pick, invoice. Invoicing is what pushes the order into ShipStation, so a missed step means a customer standing at a counter waiting for a box that never left.
The obvious way to build that job is to check status codes. Every call comes back 200. That is the problem.
Allocate returns 200 and allocates nothing
If an order's credit status is still Pending, PUT orders/<id>/allocate answers HTTP 200 with an empty error array. Nothing is allocated. Nothing in the response says so.
The fix has two parts. The order of steps matters: approve credit before you allocate. And each step proves itself on the record, not on the response. After allocate, re-read the order and confirm the allocated quantity moved. After pick, confirm the picked quantity moved. After invoice, confirm an invoice id came back.
The invoice that looked like a failure
Then the opposite problem. PUT pick_tickets/<id>/invoice returned 200, the immediate re-read showed no invoice, and our job reported a failure. The invoice existed. It reached ShipStation and shipped that morning. ApparelMagic's read-back simply lagged by a few seconds.
A false failure is worse than a real one when the step cannot be undone. The order looks stranded, and the only way to double-invoice a customer is for a person to act on that report and invoice it again. So the job now re-reads with a widening gap, 2, 4, 8 and 16 seconds. Only the read is retried. Re-sending the invoice call would bill the customer twice.
Errors that arrive as success
ApparelMagic returns 200 on a bad parameter too. The complaint sits in meta.errors and the response array is empty. Ask for a page size under 10 and you get exactly that: a polite error in the envelope and no rows. If your code only checks whether rows came back, an empty result reads as "nothing to do," and the job reports a quiet, healthy morning.
The rule we run on
Every write is judged on a re-read. Each step is reported as done, failed, or "do this by hand," and nothing that did not take is ever reported as done. Read, write, read again, compare every field.
One useful counterpoint: ApparelMagic's order PUT is a true patch. Send three fields and it changes those three and nothing else. We verified that by writing to a live order and diffing every key. ShipStation's createorder is the opposite, and that is the next note.
If your ApparelMagic jobs check status codes and not records, I'm glad to look at them with you. Get in touch.