account
Plans
What each plan includes, rendered from the live price list, and what actually distinguishes them — which is records and entitlements, not features.
1The plans
Every plan gets every REST endpoint. What changes up the ladder is the monthly record allowance, the request ceilings, and two entitlements.
In depthWhy it exists, what it is not, what people get wrong
There is no feature-gating of the data itself: the free plan queries the same live ledger, with the same fields and the same provenance, as the most expensive one. That is deliberate — a product whose pitch is auditability cannot ask you to pay to check its claims.
| Plan | Price | Records / month | Requests / day | Requests / min | Delta feed | Bulk export |
|---|---|---|---|---|---|---|
Exploreexplore | Free | 1,000 | 5,000 | 30 | no | no |
Growthgrowth | €80/month | 60,000 | 100,000 | 120 | yes | no |
Signalsignal | €299/month | 400,000 | 400,000 | 300 | yes | yes |
Scalescale | €899/month | 2,000,000 | 1,000,000 | 600 | yes | yes |
Rendered from /public/plans when this page was built. Only purchasable plans appear there, so this table is the price list — if a plan is not here you cannot buy it. Compare on /pricing.
This table comes from /public/plans, which lists only purchasable plans. If a plan is not here, you cannot buy it. Compare and buy at /pricing.
Exact contractTypes, defaults, ranges, errors, edge cases
| Dimension | What it is | Where it bites |
|---|---|---|
records_per_month | The licence. How many rows you may receive in a month. | The real ceiling on almost every integration. Exhausting it is a 402. |
req_per_day / req_per_min | Burst protection for the origin. | Rarely the binding constraint above the free tier. Exceeding it is a 429. |
delta_feed | Entitlement: /v1/changes and /v1/jobs/expired. | Without it, keeping a mirror current means re-reading listings — far more records. |
bulk_export | Entitlement: /v1/export. | Without it, a full-corpus pull means paging. |
single_country | The country-locked SKU: one country, exempt from the record meter for job rows. | Detail. |
| max page size | The largest limit the plan allows. | A plan property, not a constant — and not published on any endpoint, so it can only be observed by counting the rows you get back. Requests above it are clamped rather than refused. |
2The two entitlements
delta_feed and bulk_export are the only endpoints a plan can lack. Missing one is a 403 that names it in a header.
In depthWhy it exists, what it is not, what people get wrong
A plan without delta_feed cannot call /v1/changes or /v1/jobs/expired. A plan without bulk_export cannot call /v1/export. Everything else is available on every plan, including the free one.
The refusal is explicit rather than silent: HTTP 403 with X-JOA-Required-Feature: delta_feed or bulk_export, so a client can report exactly what is missing rather than “forbidden”.
Exact contractTypes, defaults, ranges, errors, edge cases
curl -s -D - -o /dev/null -H "Authorization: Bearer $EXPLORE_KEY" \
'https://api.jobopportunitiesapi.org/v1/changes?since=2026-08-01T00:00:00Z&limit=2'
# HTTP/2 403
# x-joa-required-feature: delta_feed/v1/me reports the plan but not the entitlements directly; the dashboard shows them per key as an Includes row, and /public/plans lists them per plan. In code, read /public/plans and match on your plan name rather than hard-coding which tier has what.
3Choosing one
Estimate records, not requests: rows you will receive per month, including every re-read. That number picks the plan.
In depthWhy it exists, what it is not, what people get wrong
- Count the rows in your slice.
/public/coverage/countriesand/public/facetsgive you this keylessly, for free, before you buy anything. - Decide how often you re-read them. This is where most estimates go wrong. A daily full re-read of a 60,000-row slice is 1.8 million records a month; the same slice kept current with
/v1/changesis a fraction of that. - Add the seed. The first full pull costs one record per row, once.
- Add a margin. Development, retries and re-processing are all real records.
- Then pick the plan whose
records_per_monthcovers it, and check it has the entitlements your design needs.
If the answer is “a daily full re-read is too expensive”, the answer is usually not a bigger plan — it is the delta feed, which is specifically the tool for that problem and is included from Growth upward.
Exact contractTypes, defaults, ranges, errors, edge cases
| Shape | Records per month, roughly | Notes |
|---|---|---|
| Evaluation, by hand | hundreds | Or none at all — /public/* is keyless. |
| A niche board, one country + category, delta-synced | seed + what moves | The seed dominates in month one and then almost nothing. |
| A board over a whole country, daily full re-read | live rows × 30 | Usually the wrong architecture. Switch to the delta feed. |
| CRM enrichment, 5,000 domains weekly | rows returned × 4 | Cap limit to what you store. |
| Research corpus, one-off | the corpus, once | Use /v1/export — needs bulk_export. |
| Whole-ledger mirror, kept current | seed + daily changes | Needs delta_feed; bulk_export makes the seed far easier. |
Every one of these is measurable before you pay: run the query keylessly, look at the counts, and multiply. If you would rather have somebody check the arithmetic, /contact reaches a person.
4Grant keys and the free tier
The free Explore plan needs no card and does not expire. There is also a grant key for research and non-commercial work, by application.
In depthWhy it exists, what it is not, what people get wrong
Explore is not a trial. It has no expiry date, it needs no payment details, and it gives you every REST endpoint against the live ledger. What it does not have is the delta feed, bulk export, or a large record allowance.
Grant keys exist for research, journalism and non-commercial work: a larger record allowance than Explore and the delta feed, still at no cost. They are not on the price list because they are not purchasable — apply at /contact?topic=grant and say what you are building.
Exact contractTypes, defaults, ranges, errors, edge cases
Because grant keys are not purchasable they do not appear on /public/plans, which lists active, buyable plans only. That is why a grant key's plan name may not match anything in the table on this page — read your own key's limits from /v1/me and the dashboard rather than from the price list.
You can hold several keys at once, on different plans. The record allowance is per key, not per account, so splitting environments across two keys also splits the meter — which is usually what you want, since it stops a runaway staging job from spending production's allowance.
This page was rendered 12 September 2026, 02:03 UTC. Every figure on it comes from the endpoint named beside it, and every published request is re-sent against the live API before this site is allowed to build. If something here is wrong, the thumbs-down above reaches a person.