Skip to main content

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 separate ReceivableClaim 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-Key per logical POST command.

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 as DEBTOR_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.
The claim’s 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 exact your_reference.

Staged-title repair details

Create a type: "titled" draft with success_fee_confirmed: false and an empty claim list. Add a titled claim with POST /v2/claims/:
Manage the claim-owned singleton later with PUT /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 return 422 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:
  1. Because deletion is permanent, preserve any needed data client-side before deleting the claim.
  2. Send DELETE /v2/claims/{claim_id}/.
  3. Send POST /v2/claims/ with "type": "titled", only neutral claim fields, and an inline enforceable_title.
These claim mutations are draft-only, so complete the repair before finalizing. Upload exactly one primary 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 as ReceivableClaim entries ("type": "receivable"). Omit legal_basis.claim_type_code; paywise derives K014. For example:
In titled totals, 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 a PATCH, 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_confirmed as anything but JSON true or false, starting_approach or creditor_obligation_fulfilled sent on a titled order (even as null), principal_amount, dates, items, charges, reminders, or a legal basis on a titled claim, a served_on or legally_binding_since earlier than issued_on, or an unknown title_type. Correct the field paths named in errors[] and issue a new logical command.
  • 409: a second primary enforceable_title document (delete the old draft document first), an immutable-field change such as the order or claim type, a DELETE …/enforceable-title/ while title documents still exist (the envelope lists them in document_ids[]), or a lifecycle conflict — including an order merged into another order, which answers Order was merged into another order. on every write; an expired draft answers 409 order_expired on every write. Refetch the order before deciding. A PUT or PATCH on the title that repeats the stored values is a 200 no-op and leaves updated_at and the ETag unchanged.
  • 422 on finalize: an incomplete titled claim (missing amount, title metadata, or primary title document — a title-less claim reports claims.{claim_id}.enforceable_title / required), success_fee_confirmed still false, 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, or 503: read the order by ID before deciding on a retry. Only an observed draft justifies repeating finalize with the same key.
  • 429: wait at least the integer seconds in Retry-After, then retry the same command and key.

Verify

Require .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. 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.