Submit Order

SubmitOrder. Idempotent on centrics_order_id.

⛔A REPUSH IS NOT A SECOND ORDER. He retries on his own schedule, and a duplicate that created a twin could be printed twice -- which is real mail to a real person, twice, with no undo. Answers 200 with already_existed either way rather than a conflict, because a retry succeeding is what he needs to see.

⛔APPENDED 2026-10-08: a repush of an order that has never printed also REPLACES its recipient and sender with the repush's (his orders now carry the inmate number in recipient.attention, consumer/api#112); the answer's address says updated or unchanged. An order that printed, has a print job or had an envelope scanned is never changed.

⛔APPENDED 2026-10-09 (Frederick, new print templates backfilled by repush; OPEN_ITEMS RPA-1): the same repush also REPLACES the document of each pushed line that has not printed and has no live job; the answer's documents and document_lines say what happened to each line and why anything was refused. A line that printed, is on a press or belongs to an order whose envelope was scanned is never changed.

⛔APPENDED 2026-10-09 (OPEN_ITEMS RPA-6; Jonathan: "something that replaces an order's lines and drops the receipt"; Frederick: "We can only take your file so you have to update your file"): a repush that carries the order and leaves out its retired receipt (receipt.pdf, greeting-card-receipt.jpg) WITHDRAWS that line, keeping the row; document_lines gains an entry for it, receipt_withdrawn or a refusal. A photo receipt is never dropped; no other line is ever removed.

⛔APPENDED 2026-10-11 (OPEN_ITEMS ROD-1; Frederick: "the backlog is addressed first, and then we catch up"): the push may carry retailer_order_date, when the order was placed (RFC 3339 with an offset; a time with no offset is a 422). A new order stores it. A repush of an order with NO stored date fills it; a repush whose date differs from the stored one changes nothing and says so on the order's trail and in the answer's order_date (differs). The ready list and the floor work the oldest order first by it (print_order.order_clock_sql).

⛔APPENDED 2026-10-11 (the lead; print.order_duplicates, FLR-25 History): a NEW order whose lines are the same document for the same parcel code as an order Roost already holds (the signed link may differ) is recorded as a DUPLICATE and never printed. It is still a 200 with already_existed true, the original's OrderStatus, duplicate true and duplicate_of naming the original: a retry of a parcel under a new order id is received, not refused, and nothing is lost.