Can I send the same shipment twice?

Do not treat repeated POST requests as idempotent. The public API has no supported Idempotency-Key header. item.invoiceReference is an optional business reference (maximum 34 characters), not a unique key or a lookup endpoint. Reusing it does not guarantee the original response.

A repeated request may create another assignment or add shipment data to an existing buffered assignment, depending on account settings. Receiving the same assignment ID is not proof that no duplicate shipment was added.

1. Record the booking attempt before sending

   Persist your own unique source-delivery identifier and mark it as in progress. Prevent concurrent workers from booking the same delivery.

2. Save a successful response

   Store the returned assignment ID against that source delivery. Use GET /assignment/single/{id} to retrieve or reprint; do not repeat POST to obtain a label.

3. Reconcile an uncertain result

   After a timeout, dropped connection or ambiguous server error, stop automatic POST retries. If you have an assignment ID, retrieve it. Otherwise check the portal or contact support with the environment, business reference and request time before deciding to rebook.

4. Correct a definite rejection

   For an explicit validation or permission rejection, correct the cause first. If the response does not establish whether creation occurred, reconcile it before trying again.