Skip to main content

Outcome

The Partner created one draft for the exact company, finalized it only after a fresh ready/access check, and verified the exact order URL. Company, order, and claim UUIDs came directly from authoritative responses. Readiness does not block draft creation. Access and readiness are independent: access must be available for every delegated call, while readiness gates only finalization. The company UUID belongs solely in X-On-Behalf-Of-Company, never in the request body.

1. Check current access independently

Read the exact Company management URL without the delegation header.
Require case_access == "available". Inspect readiness for the UI, but do not use a false value to suppress draft creation.

2. Prove the sandbox before draft creation

Create or reuse the delegated debtor

Use the Case Management API with the same X-On-Behalf-Of-Company header as the order. The company UUID never belongs in either JSON body. Each tab parses the exact returned debtor UUID and persists it as DEBTOR_ID.

Prove the sandbox before order creation

The debtor write and order write are separate commands. Re-check the authenticated environment immediately before creating the order.

3. Create the delegated draft

Capture the required order id and claim id directly. An ambiguous create replays the same key, body, and company header within a bounded budget.

Staged claim alternative

To build an empty delegated order in stages, send a separate logical command with a distinct stable key and the same tenant header:
Require the 201 response’s your_reference to equal the exact submitted business reference, then persist its id. Replay only with the same key, tenant header, and body.

4. Re-read current readiness

Require both current access and current readiness. If readiness remains false, retain the draft and remediate; do not finalize.

5. Prove the sandbox before finalization

6. Finalize with an empty body

Finalize accepts an empty body or exactly {}; any member is 400 validation_error with unknown_field. Keep the company UUID in X-On-Behalf-Of-Company, never in the JSON body.

7. Verify the exact delegated order URL

Runnable delegated submission workflow

Python workflow

Representative response

Failure and recovery

  • Retry an ambiguous create/finalize only with the same key, body (when any), company header, and bounded attempt budget.
  • 404 can mean wrong tenant or revoked access. Refetch the exact Company and do not recreate inaccessible Partner drafts blindly.
  • A readiness error retains the editable draft. Remediate, re-read current readiness, and then issue the original logical finalize command.
  • Any access event gates queued writes until current Company state is reconciled. Finalized cases remain available through company/staff channels.

Reconcile acceptance by claim UUID

Webhook deliveries are at least once. On order.accepted, intersect the event’s claim_ids with the claim UUIDs stored by exact business reference. For every match, refetch /v2/claims/{claim_id}/ and trust the claim’s current order_id and mandate_id, even when the event order differs from the originally submitted order. The claim UUID remains stable; do not scan orders or reconstruct merge chains.