Count Endpoints
The count endpoints return the number of listings matching your filters in a time window. No job rows are returned in the body, just the total.
| Endpoint | Counts | Pairs with |
|---|---|---|
active-ats-count | ATS listings (company career pages) | active-ats |
active-jb-count | Job board listings (LinkedIn, Wellfound, Y Combinator) | active-jb |
When to use them
Sizing a subscription plan. Call with time_frame=1m to see how many jobs match your filters per month. This window counts every job indexed during the last 31 days including jobs that have since expired. This is the most direct way to pick the plan you need before subscribing. For ballpark per-country volumes without writing a query, see Country Job Statistics.
Estimating a backfill. Use time_frame=6m to calculate how many jobs a full backfill will pull from active-ats / active-jb before you run it. This window counts active listings only, the same set the data endpoints serve, so the number maps directly onto the Jobs credits the backfill will consume. See Recommended Strategy for the backfill flow.
When not to use them
You don't need a count to paginate. Don't call a count endpoint to figure out how many times to increase offset on the data endpoints. Just keep increasing offset by your limit until a response returns fewer rows than limit - that's cheaper than a separate count call. See pagination.
time_frame values
The count endpoints accept every time_frame the active-jobs endpoints accept, plus 1m - which is also the default.
| Value | Window | Includes expired jobs | Notes |
|---|---|---|---|
1h | Last hour | No | Count of just-discovered jobs. |
24h | Last 24 hours | No | |
7d | Last 7 days | No | |
1m | Trailing 31 days | Yes | Default. Best for monthly plan estimates. No equivalent window on the data endpoints. |
6m | Last 6 months | No | Slow and likely to hit the 60s timeout on broad queries. Use sparingly. description / description_advanced are not allowed on this window. |
`1m` counts a different set of jobs than the other windows
1h, 24h, 7d, and 6m count currently active listings only, so they match what active-ats / active-jb would return for the same window and filters - jobs that have expired are dropped from those windows (see Expired Jobs).
1m counts every job indexed in the last 31 days, including jobs that have since expired. It is a measure of monthly indexing volume rather than a snapshot of what's live right now, which is why it's the right window for plan sizing but has no counterpart on the data endpoints.
One practical consequence: a 1m count lands close to the sum of 31 consecutive daily 24h calls, whereas a single 7d or 6m count comes in lower than the sum of the daily calls covering the same period. The gap is jobs that expired in the meantime, and it widens the further back the window reaches.
Parameters
Both count endpoints accept the same filters as their data counterparts - title, location, source, organization, the ai_* filters, date filters, etc. (see All parameters) - with the response-shaping and pagination parameters removed, since there are no rows to shape or page:
| Endpoint | Excluded parameters |
|---|---|
active-ats-count | description_format, include_basic_organization_details, id, limit, offset, cursor |
active-jb-count | description_format, exclude_recruiter_fields, employment_type (raw), id, limit, offset, cursor |
description / description_advanced are accepted on 1h, 24h, 7d, and 1m, but not on time_frame=6m.
Cost & timeouts
These endpoints scan the full filtered set
A count call scans the entire matching set every time and is not designed for frequent use. Each call:
- consumes 1 API Request (not Jobs credits - counts don't draw down your job quota), and
- times out after 60 seconds, which broad
6mqueries are likely to hit.
If your queries are complex and timing out, reach out to us rather than retrying aggressively.
See Plans, Limits & Upgrades for how API Requests are metered.