Outcome
Your application has a current mandate read model and one durable, paginated feed of the activity paywise published for the relevant main/subcase tracks.Prerequisites
- A Bearer key.
- The stable claim UUID retained at submission and the exact mandate UUID —
from the claim’s current
mandate_id, theorder.acceptedpayload’smandate_id, ormandate.created.
order.accepted includes the stored claim UUID in data.claim_ids, read
GET /v2/claims/{claim_id}/ once. Require claim status accepted and require
its mandate_id to match the event, then store the claim’s current order_id.
The submitted order ID is informational after review: do not reconstruct
order-merge chains, and never follow merged_into before a claim command.
1. Read the known mandate
main_case and subcases before deciding which tracks to render. The
mandate’s state is the authoritative current legal, processing, and payment
state. For the overall case, read the main mandate; for one subcase, read that
subcase’s mandate resource. Detail does not embed top-level document, payment,
statement, or request-to-client collections; claim documents remain below
their claims.
2. Walk unified history
next URL until it is null. Each row’s
source_mandate identifies the main or subcase track. A main-mandate request
includes published entries for the main case and all valid subcases. A direct
subcase request includes that subcase only.
Each row is one published status, even when it has several attachments or
related resources. related_resources can contain references to a
request_to_client, message, email, or single_mandate_statement. Use
expand=history.related_resources when the documented expanded bodies are
needed and the credential can read them. Email references have url: null;
their optional expanded body supplies client-visible subject, date, and
direction metadata.
Representative response
MandateHistoryPage.
Use updated_since for incremental reads. The cutoff is inclusive and rows
expose updated_at, so persist the greatest applied timestamp, overlap the
next sweep, and upsert entries by status id, keeping their newest version.
Only advance the saved timestamp after every page has been applied. An entry
can reappear when an attachment or linked resource changes. With a cutoff,
rows are ordered by updated_at and then id; without one, they are ordered
newest first by event time and then id. Follow the shared
pagination and synchronization guidance
for overlap windows and recovery after an interrupted read.
Runnable Python workflow
Python workflow
download_url values. A null download_url means no file
is available; keep the attachment metadata without attempting a download.
Failure and recovery
403: verify the selected company and contact paywise support if access is unexpectedly denied.404: verify the selected company and exact mandate UUID.400 invalid_parameteron a list: use the documented filters and values. Unknownorderingterms on the mandate, order, and statement lists are refused the same way; the retiredsortanddirectionparameters are400 unknown_parameter.429: wait at leastRetry-After, then resume from the exact last uncommittednextURL.- Duplicate or out-of-order webhook signals: refetch the mandate and upsert
rows by stable server
id; never select the first list row or infer state from event order.
Verify
.id to equal the mandate UUID you follow and .state to carry
legal_stage, processing, and payment dimensions, each with a code.
Require every history row to have updated_at, source_mandate,
related_resources, and attachments. Treat blank state values in a history
entry as event context; use the mandate’s current state for decisions.
