limit
defaults to 10 and accepts 1–100; offset is the zero-based position.
Both are validated, not coerced: a non-integer value (ASCII digits only),
limit outside that range, or a negative offset returns
400 validation_error with errors[].code = "invalid_parameter" on the
parameter — a limit above 100 is no longer silently capped. Follow the returned next URL instead of
rebuilding it, and stop when next is null.
Sort order uses one query parameter, ordering, on every list that can be
sorted: the order and mandate collections (name, created, amount,
status), the statement collections (for example ordering=-booking_date),
the Partner company list, and the Mahnservice invoice (created, due_date,
amount, invoice_number) and debtor (created, customer_number) lists.
Terms are comma-separated, and a - prefix sorts descending. Without
ordering, the order, mandate, statement, and Mahnservice lists are newest
first; on the order, mandate, and Mahnservice lists ties are broken by id.
Every other list is ordered as its reference documents. An undeclared
parameter — including the retired sort and direction — is 400 with
unknown_parameter, so read the operation reference before adding one.
An empty ordering= value is treated as omitted and keeps the default.
Otherwise ordering is strict: an unknown field or an empty comma-separated
term (for example created,,name) is 400 validation_error with
invalid_parameter on ordering.
Not every collection is paginated. In particular, the immutable Case and
Partner legal-form catalogs return an unpaginated JSON array and may be cached
privately for one day.
Incremental synchronization
Mutable collections of the Case Management and Partner APIs accept a timezone-aware RFC 3339updated_since; a naive timestamp or another format
is 400 validation_error with invalid_parameter. The filter is inclusive
and results are stably ordered by updated_at, then id. The Mahnservice
API offers offset pagination only — its updated field on invoices and
documents is a change marker to compare, not a filter.
There is no snapshot or cursor guarantee: writes during a scan can move rows
relative to an offset and cause a page-only consumer to miss them.
Use an overlapping reconciliation window instead of treating one offset scan
as complete:
- For the initial sync, omit
updated_since. Thereafter, store a high-water timestamp and choose an overlap longer than the longest expected full page sweep. Query fromhigh_water - overlap. - Follow every returned
nextURL. Reconcile each row by(id, updated_at), retaining the newest representation and safely accepting duplicates. - After all pages are durably applied, move the high-water timestamp to the
greatest observed
updated_at. Keep applying the overlap on the next run. - If a scan takes longer than the overlap, is interrupted, or runs during unusually heavy writes, do not advance the high-water timestamp. Repeat from the same lower bound with a larger overlap.
- Run a periodic full reconciliation (omit
updated_since, or use a retained older floor) to repair any row movement outside the operational overlap.
Synchronize claims by stable UUID
The claim collection acceptsorder_id, effective status, and
updated_since together. For example:
order_id changes and its updated_at
advances. A change to the current order’s debtor projection likewise advances
the claim cursor because debtor_id or additional_debtor_ids changed in the
claim read.
Follow the exact next URL returned by the server, including every filter. A
page can, for example, return
https://api.paywise.de/v2/claims/?limit=100&offset=100&order_id=20000000-0000-4000-8000-000000000001&status=submitted&updated_since=2026-08-27T09%3A00%3A00Z.
Do not rebuild that URL or assume later pages still contain the same rows.
Across overlapping sweeps, deduplicate claim versions by (id, updated_at) and
retain the newest complete representation. A stored claim UUID can always be
confirmed directly at /v2/claims/{id}/, without scanning orders.
Runnable reconciliation example
This Python example synchronizes the Case Management API’s debtor collection. Use the same approach for other mutable collections that supportupdated_since,
with a separate checkpoint for each company and collection. The key needs
read access to the collection being synchronized.
The example starts from a previously saved timestamp and keeps its results
in memory. In your application, load that checkpoint and the existing local
records, then persist each applied page before advancing the checkpoint.
For the initial import, omit updated_since and follow all pages.
Python workflow
GET /v2/mandates/{id}/history/. Its updated_at includes changes to
represented attachments and linked resources, so update existing entries
by status id when they reappear. See
Follow a case for
main-case and subcase selection and the complete history representation.
Recover interrupted syncs
After a timeout or transient5xx, retry the same next URL. If its result may
already have been applied, upsert by id so replay is harmless. After 429,
wait for Retry-After, then resume from the last uncommitted page. If a stored
URL is no longer usable, restart from the last committed updated_since
lower bound rather than guessing a larger offset.
See the current orders collection,
mandates collection, and
Partner companies collection
for supported filters and response shapes. The
Case legal-form catalog
shows the unpaginated exception.