Outcome
You have a finalized titled order with at least one complete titled claim, its primary title document, and an explicit success-fee confirmation. Optional enforcement costs remain separateReceivableClaim entries.
Enforcement is automatic for
type: "titled". Omit starting_approach
and creditor_obligation_fulfilled on create and update; sending either
field, even as null, returns 400. Do not send
starting_approach: "enforcement": enforcement is derived by paywise,
and the titled-order response does not expose a starting-approach field.Prerequisites
- A production or sandbox base URL and Bearer key.
- An entitled company UUID on every call when using a Partner key.
- A debtor UUID with sufficient address and notification data.
- Per titled claim: the enforceable title’s kind, issuing authority, file number, issue date, gross amount, and the title document as PDF, JPEG, or PNG (10 MiB at most).
- One stable
Idempotency-Keyper logicalPOSTcommand.
Lifecycle context
A titled order follows the same draft →submitted → accepted lifecycle
as an invoice order. Enforcement is implicit: there are no starting-approach
decisions, and finalization additionally requires success_fee_confirmed: true. Each TitledClaim owns one enforceable title singleton whose amount
is authoritative; enforcement costs are ordinary ReceivableClaim entries.
Documents scan asynchronously and never block finalization.
0. Create or reuse the debtor
Create the reusable debtor first. Each example parses the exact returned UUID; persist it asDEBTOR_ID and use that value in the order request. Reconcile
an ambiguous retry by the exact your_reference; never guess an ID.
1. Create inline
Use one POST/v2/orders/
when the title and its evidence are ready. The order, claim, title, payment,
and document writes commit atomically.
type must be titled. The title’s amount, metadata, and
documents are authoritative. Do not send principal_amount, items, charges,
dates, reminders, legal basis, or generic claim documents on a titled claim. Its response has
principal_amount: null, and total_amount mirrors the title amount.
served_on and legally_binding_since are optional finalization fields, but
normally supply service date and proof of service when available so paywise
can assess enforcement without a later clarification. Neither date may be
earlier than issued_on.
2. Choose the exact title kind
title_type accepts only the generated enum:
3. Build the draft in stages
Create the empty titled draft first, then use a distinct stable idempotency key for the claim command. Preserve the exact key and body for replay, and store the returned claim UUID only after verifying the exactyour_reference.
Staged-title repair details
Create atype: "titled" draft with success_fee_confirmed: false and an
empty claim list. Add a titled claim with
POST /v2/claims/:
/v2/claims/{claim_id}/enforceable-title/
or
PATCH /v2/claims/{claim_id}/enforceable-title/.
PUT creates it if absent (201) or replaces all writable metadata and
amount (200); omitted writable fields are cleared, but documents remain, and
an empty body is 400. The title exists only on a titled claim: on a
receivable claim of the order, such as K014 enforcement costs, PUT, PATCH,
and DELETE …/enforceable-title/ answer 404
(No enforceable title found for the given reference.). PATCH changes only
supplied fields. Draft-only
DELETE removes the title metadata; it conflicts with 409 (listing
document_ids[]) while title documents exist, so delete those documents
first. The claim stays type: titled with enforceable_title: null until you
PUT a new title or delete the claim.
Repair an incompatible titled draft
An existing or staff-converted draft can return422 readiness errors for
incompatible ReceivableClaim fields on a titled claim, such as
claims.{claim_id}.items or claims.{claim_id}.additional_charges. The
supported public repair is to replace that Claim while the order is a draft:
- Because deletion is permanent, preserve any needed data client-side before deleting the claim.
- Send DELETE
/v2/claims/{claim_id}/. - Send POST
/v2/claims/with"type": "titled", only neutral claim fields, and an inlineenforceable_title.
enforceable_title document below the singleton.
Additional other documents are allowed. Creating a second primary returns
409 until the old draft document is deleted.
4. Add enforcement costs separately
A titled order may contain ordinary enforcement costs asReceivableClaim
entries ("type": "receivable"). Omit legal_basis.claim_type_code; paywise
derives K014. For example:
main_claims combines authoritative title amounts and
ReceivableClaim principals. charges contains only receivable-claim additional
charges, and order_value is their gross sum. Payments are reported
separately and do not reduce those gross totals.
5. Confirm and finalize
Before finalizing, patch the draft with{"success_fee_confirmed": true}.
This explicitly acknowledges the success-fee condition and is required even
when every title is otherwise complete. See the
paywise General Terms and Conditions (AGB) for the
exact conditions for titled orders.
Finalize with an empty-body
POST /v2/orders/{id}/finalize/
and a fresh Idempotency-Key. Each titled claim must have a positive
amount, title type, issuing authority, file number, issue date, and primary
title document. An incomplete aggregate returns 422; invalid values return
400; immutable, duplicate-document, and lifecycle conflicts return 409.
Read the order after an ambiguous outcome, withdraw it only while submitted
and eligible, or delete the whole order while it is still a draft.
Runnable Python workflow
This orchestration proves the sandbox before any write, creates the titled draft with the success fee unconfirmed, confirms it with aPATCH, uses one
generated key per logical POST, and never automatically repeats an ambiguous
finalize call.
Python workflow
Failure and recovery
400 validation_error:success_fee_confirmedas anything but JSONtrueorfalse,starting_approachorcreditor_obligation_fulfilledsent on a titled order (even asnull),principal_amount, dates, items, charges, reminders, or a legal basis on a titled claim, aserved_onorlegally_binding_sinceearlier thanissued_on, or an unknowntitle_type. Correct the field paths named inerrors[]and issue a new logical command.409: a second primaryenforceable_titledocument (delete the old draft document first), an immutable-field change such as the order or claimtype, aDELETE …/enforceable-title/while title documents still exist (the envelope lists them indocument_ids[]), or a lifecycle conflict — including an order merged into another order, which answersOrder was merged into another order.on every write; an expired draft answers409 order_expiredon every write. Refetch the order before deciding. APUTorPATCHon the title that repeats the stored values is a200no-op and leavesupdated_atand theETagunchanged.422on finalize: an incomplete titled claim (missing amount, title metadata, or primary title document — a title-less claim reportsclaims.{claim_id}.enforceable_title/required),success_fee_confirmedstillfalse, or incompatible receivable fields on a titled claim — see Repair an incompatible titled draft. The draft stays editable; complete it and finalize with a fresh key.- Finalize timeout,
500, or503: read the order by ID before deciding on a retry. Only an observeddraftjustifies repeating finalize with the same key. 429: wait at least the integer seconds inRetry-After, then retry the same command and key.
Verify
.type to be titled, .status to be submitted or accepted,
.success_fee_confirmed to be true, and every claim with type titled
to carry enforceable_title.amount and a primary title document before
recording the workflow as successful.
Reconcile acceptance by claim UUID
Webhook deliveries are at least once. Onorder.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.
