# 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`](/api/new-jobs#ats-jobs-count) | ATS listings (company career pages) | [`active-ats`](/api/new-jobs#ats-jobs) |
| [`active-jb-count`](/api/new-jobs#job-board-jobs-count) | Job board listings (LinkedIn, Wellfound, Y Combinator) | [`active-jb`](/api/new-jobs#job-board-jobs) |

## When to use them

**Sizing a subscription plan.** Call with `time_frame=1m` (jobs indexed during the last 31 days) to see how many jobs match your filters per month. This is the most direct way to pick the plan you need before subscribing - and it's included in the free trial, so you can size up before paying. For ballpark per-country volumes without writing a query, see [Country Job Statistics](/documentation/country-job-statistics).

**Estimating a backfill.** Use `time_frame=6m` to calculate how many jobs a full backfill will pull from [`active-ats`](/api/new-jobs#ats-jobs) / [`active-jb`](/api/new-jobs#job-board-jobs) before you run it. See [Recommended Strategy](/documentation/recommended-strategy#backfill) 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](/documentation/endpoints/new-jobs#pagination).

## `time_frame` values

The count endpoints use a **different `time_frame` set** from the active-jobs endpoints - note the `1m` default and that there is no `7d`.

| Value | Window | Notes |
| --- | --- | --- |
| `1h` | Last hour | Count of just-discovered jobs. |
| `24h` | Last 24 hours | |
| `1m` | Trailing 31 days | **Default.** Best for monthly plan estimates. |
| `6m` | Last 6 months | Slow and likely to hit the 60s timeout on broad queries. Use sparingly. `description` / `description_advanced` are not allowed on this window. |

## 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](/documentation/endpoints/new-jobs#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`, and `1m`, but **not** on `time_frame=6m`.

## Cost & timeouts

:::warning{title="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 `6m` queries are likely to hit.

If your queries are complex and timing out, [reach out to us](/contact) rather than retrying aggressively.

:::

See [Plans, Limits & Upgrades](/documentation/credit-usage) for how API Requests are metered.