Skip to main content
Two kinds of filter, all optional, all ANDed together. GET /fields?object=account (or contact, signal, …) lists every key, whether it can be filtered, its operators and its values.

Any key: filter[<key>]

/accounts and /contacts filter on any key their rows carry:
Repeat filter[<key>] for any of several values. A key inside a list (contacts.<key>, signals.<key>, contacts.signals.<key>) matches when any element matches, and ne when none does. account_competitors matches one competitor at a time. Contact emails and phones need include=contact_info; buying-committee and job-postings keys need their include. filter[...] on a key and operator /fields lists in fast_operators (priority, stage, competitors, owners, country, signal dates, …) narrows the table read itself, as the dedicated filters below do. On any other key it filters the rows of the query, so the first request of that filter set reads the whole table; later pages are cached. Combine a slow key with a fast one to keep the read small.

Analytics periods

Every /analytics metric requires start_date and end_date (YYYY-MM-DD, UTC, both inclusive) and reports on that period only: the accounts whose latest signal falls in it, and the deals created, meetings booked, outreach, replies and closed deals dated in it. Nothing is reported over a rolling window; data.period echoes the dates back.

Dedicated filters

/accounts, /contacts and every /analytics metric take these as plain query parameters (analytics takes only these, minus the *_within_days and *_older_than_days ones). A filter is named after the key it filters and takes that key’s values. A list filter repeats its parameter for several values (?account_priority=High&account_priority=Medium), which matches any of them. Do not comma-join: names can contain commas. Unknown parameters and values are rejected with a 422 that names them.