Skip to main content
Pagination support differs by surface, and the difference is deliberate rather than a work in progress.
The carrier surface returns every matching record in one response, with the single exception below. There is no page parameter to add on the rest, and adding one later would change the shape of a response that integrations already parse. Size your timeouts and your memory for the whole result set, and use the filters each endpoint offers to keep it small.

​
The one paginated carrier endpoint

GET /v2/upstream/policies/{policyId}/transactions and its v1 twin GET /v1/policies/{policyId}/transactions are paginated. Both accept page (default 1) and limit (default 50, maximum 100) and return a page envelope, not a bare array.
If you are reconciling a policy with more than 50 transactions, you must follow the pages. A single call returns the first 50 and stops. Nothing in the response is an error, so a client that reads only the first page silently drops the rest of the policy’s history. Read totalPages on every call to this endpoint and keep requesting until you reach it.
The envelope carries the same total, page, limit and totalPages fields as an agency list, but keys its array on transactions, not items. That is the older convention and it is frozen where it is.
Full parameters are on the List Transactions reference page.

​
Paging an agency endpoint

Two query parameters, on every list: A request above the limit is refused rather than quietly reduced, so a client asking for 500 finds out immediately instead of paging through a result it believes is complete.
Page until page reaches totalPages, or until items comes back empty. Both are reliable.
items, not the resource name. Every agency list uses the same key, so one generic client type reads all of them. The paginated carrier endpoint (GET /v{1,2}[/upstream]/policies/{policyId}/transactions) is the one place a paginated array carries the resource name instead.

​
Ordering is stable across pages

Every agency list sorts by a meaningful key and then by record id. That second term is what makes paging safe: ordering by a non-unique key alone lets records shift between pages as you walk them, so you see one twice and miss another entirely, with no error anywhere. You do not need to do anything for this. It is worth knowing because it is the reason you can trust page 2 not to repeat page 1.

​
Filtering

Filters are per endpoint and documented on each reference page. The common ones on the agency surface:
  • downstreamEntityId — narrow a list to one of your entities. An id outside your organization returns 404. It is accepted on 21 of the 24 paginated agency lists; the three market sub-lists (/v2/downstream/markets/{upstreamDownstreamAssociationId}/documents, /entity-contacts and /market-contacts) do not take it. Those three accept only the association id in the path, plus page and limit.
  • stateCode, status — on licence and appointment lists.
  • category — on documents.
  • producerId — on producer-scoped lists.
An unknown filter value is a 400 with the accepted values in the body, rather than being ignored. A silently-ignored filter returns a plausible response to a wrong question, which is worse than an error.

​
Sorting

Sort order is fixed per endpoint and chosen to match how the list is read — documents and filings newest first, entities and contacts by name. There is no sort parameter. If a different order would be useful for your integration, tell us at support@turrisfi.com: adding one is straightforward, and it is better done once against a real need than guessed at.

Related topics

The Agency APIList ContactsChangelog