Same as the endpoint without the trailing {filters}, with filters, ordering, pagination and field selection encoded as path segments. See Core API Concepts.

Example (on GET /campaigns): GET /api/campaigns/campaign_id/42/limit/50;0

Filter rules

• <field>/<value> is an exact match, including datetimes: start_at/2026-07-01 00:00:00 matches that second only. Use a range for anything wider.
• Comparisons are written <value>;<op> with <, >, <=, >= or =: lead_id/60000;>.
• | joins conditions on one field. Between plain values it means OR (object_type_id/1|4); between comparisons it means AND, so id/3;>|5;< selects 3 < id < 5 and id/3;<|5;> matches nothing. A date range: start_at/2026-07-01 00:00:00;>=|2026-07-31 23:59:59;<=.
• Several <field>/<value> pairs are ANDed: status/NORMAL_CLEARING/object_type_id/1.
• There is no negation: !=, <> and ! are ignored (the filter matches as if it were absent or =).
• An unknown field name does not raise an error; it matches nothing, so a typo returns an empty list.
• % is rejected in the path, so LIKE-style patterns are not available.
• Filters take IDs even where the response shows a display value (e.g. campaign_id/3, while cdrs rows return the campaign name in campaign_id).

Custom call fields defined on the account can be used as filter keys and are returned on each record alongside the standard fields.