v1.0.0 - Expand list query support across API list endpoints #
Payments, invoices, and webhook event listing endpoints now support pagination, sorting, filtering, and related-record expansion through a unified query contract.
13 May 2026
List endpoints across the API now accept a consistent set of query parameters for pagination, sorting, filtering, and relation inclusion. This replaces previous per-endpoint, ad-hoc query handling with a single shared contract, giving developers a predictable and documented interface for all list operations.
What changed
- Payments, invoices, and webhook events listing endpoints accept standardized
page,limit,sort,filter, andincludequery parameters. - Filtering supports typed, operator-driven expressions (e.g. equality, range) so results can be narrowed without custom endpoints.
- Relation inclusion allows callers to request parent and original-delivery records alongside webhook events in a single response.
- Malformed or unsupported query parameters now return a clear
400 Bad Requestresponse rather than silently ignoring or mishandling the input. - OpenAPI / Swagger documentation reflects the new query contract; docs now derive the API version and title from the package version automatically.
Why it matters
Developers building merchant dashboards, reconciliation tools, or operational integrations can now paginate and filter results reliably across all major list endpoints using the same parameter names and semantics — reducing the need for client-side post-processing and extra round trips.
Developer notes
- The per-endpoint query DTOs for payments (
PaymentsQueryDto), invoices (InvoiceListQueryDto), and webhook events (ListClientWebhookEventsQueryDto) have been replaced by the shared list-query parser. Update any code that constructed or validated those DTOs directly. - Unsupported or malformed
filter/sortexpressions that were previously silently ignored will now return400. Review any existing queries that relied on lenient handling. - No database migrations are required.