Coverage & freshness

Which registers the API serves, how complete each one is, how often it is updated, and how to check this from code.

The API serves 119 national and regional registers, about 207 million records. GET /v1/jurisdictions is the authoritative, machine-readable list: it reports every register’s state, size, the span of filing years it holds, and when Pinakel last checked and changed it.

​

What each register reports

Field	Meaning
code	The register code, as used in jurisdiction filters and record ids.
name	The register’s name.
state	available, stale or reloading (see below).
record_count	Records Pinakel holds for the register.
live_record_count	Records whose status category is live.
earliest_application_year, latest_application_year	The span of filing years in the register. A late earliest_application_year means older records are not available from the source.
last_checked_at	When Pinakel last checked the source for updates.
last_changed_at	When a record in the register last changed in Pinakel.
feed_published_through	Changes up to this time are published in the changes feed.
update_frequency	How often Pinakel checks the source: daily, weekly, monthly or irregular. It follows the office’s own publication cycle.

Counts come from precomputed aggregates, not from a live count, so they can trail the newest records slightly.

​

States

state	Meaning	Effect on the API
available	Normal.	Served everywhere.
stale	The last update run for this register failed. The data is served, but may be older than its update_frequency suggests.	Served everywhere. Check last_checked_at.
reloading	The register is being rebuilt from its source.	Searches skip it and list it in unavailable_jurisdictions. Retrieving one of its records, or a feed request naming only reloading registers, gets 503 jurisdiction-unavailable with Retry-After of at least 900 seconds.

A reload republishes the whole register in the changes feed when it finishes. See How records change.

​

Freshness is two delays

How current a record is depends on two delays, and the API can only report the second:

1. The office’s delay: between an event (a filing, a decision, a renewal) and the office publishing it. Some offices publish within a day; others publish weekly gazettes or monthly bulk files.
2. Pinakel’s delay: between the office publishing and the change reaching the API. last_checked_at, last_changed_at and feed_published_through measure this part.

For a deadline that matters, confirm the office’s record before acting.

​

Checking coverage from code

GET /v1/jurisdictions returns about 120 entries in one response and is cached for 60 seconds. Call it at the start of a sync run, and:

• skip registers that are reloading, and retry them later;
• warn when a register you depend on is stale, or when last_checked_at is much older than its update_frequency;
• build your jurisdiction filters from the codes it returns rather than from a hard-coded list.

curl "https://api.pinakelai.com/v1/jurisdictions/AD" \
  -H "Authorization: Bearer $PINAKEL_API_KEY"

​

Registers

The register table is generated from GET /v1/jurisdictions when this site is published. Until then, call GET /v1/jurisdictions for the current list.

Measured coverage and freshness, with sample sizes and method, are published as dated reports in Research.