Getting started with jobs
A job processes a whole file in the background — for example 50,000 addresses to cleanse or 200,000 coordinates that need an address. You upload the file in the dashboard (or send it to POST /v1/jobs), follow the progress live and download the result as CSV or NDJSON when the job is done.
Jobs require Pro or Enterprise.
What can a job do?
| Job type | Does | Variants |
|---|---|---|
reverse | Coordinates → nearest addresses | – |
datavask | Address cleansing: corrects and validates addresses (typos included) | unit addresses (adresser) or access addresses (adgangsadresser) |
bbr | Fetches BBR data from BBR ids | buildings (bygninger) or units (enheder) |
dagi | Coordinates or postal codes → municipality, region, parish, districts and more | – |
eksport | Exports the result of a search in Find properties as CSV or JSONL | – |
Each row gives exactly the same answer as if you had sent it in a synchronous batch call.
Job or synchronous batch call?
- Synchronous batch call (e.g.
POST /v1/datavask/adresser/batch): the answer comes right away. Good for small amounts, such as a form or a small import. The limit is per call (see the table). - Job: for large files. You get a job id right away and the job runs in the background — you don't need to keep a connection open or split the file yourself.
If you send more elements in a synchronous call than your plan allows, the API responds with 400 and tells you both the limit and that you can use a job instead.
The quota is checked for the whole batch. A synchronous batch call is checked against the team's quota for the whole batch before anything is processed. If there isn't room for all the elements, the API responds 429 with type: quota_exceeded — nothing is processed, and nothing is billed. Send a smaller batch, upgrade, or wait until the quota resets. A job behaves differently: it runs until the quota is used up, stops with status kvote_stop, and the processed rows can be downloaded. That is why a job is often the better choice for large amounts. The details are in Jobs via API.
Limits per plan
| Pro | Enterprise | |
|---|---|---|
| Synchronous per call — reverse | 100 | 1,000 |
| Synchronous per call — cleansing | 100 | 500 |
| Synchronous per call — BBR | 100 | 1,000 |
| Synchronous per call — DAGI | 100 | 500 |
| Rows per job | 10,000 | 1,000,000 |
| File size per job | 24 MB | 64 MB |
| Rows per export from Find properties | 10,000 | 1,000,000 |
| Jobs queued or running at the same time | 3 | 10 |
| Result can be downloaded for | 7 days | 30 days |
| Place in the queue | normal | ahead of Pro |
Enterprise also covers Scale and custom agreements. Hobby and Basis do not include batch and jobs.
How a job is billed
- Each row that returned a result counts as one lookup in the team's quota. Rows that fail cost nothing — just like a call that fails. A job of 12,000 rows where 150 fail costs 11,850 lookups. A row with a warning (e.g. an uncertain match) did get a result and counts.
- Creating the job (
POST /v1/jobs) costs nothing. If every row fails, the job costs 0 lookups. - Exports from Find properties are billed as search pages: one lookup per started 100 rows. An export of 2,501 rows costs 26 lookups.
- Fetching the status, the result or the error rows — and cancelling — does not count towards the quota. You can also download a partial result after the quota is used up.
The quota is checked before each part of the job is processed. If the quota won't cover the whole file, you get a warning before the job starts (it assumes every row returns a result), and the job stops exactly at the quota with status kvote_stop — rows that fail never make the job stop. The rows processed by then can be downloaded. If the quota is already used up when you create the job, it is rejected with 429.
Which key is the job billed to?
A job is always counted on an API key — like a normal call with that key.
- In the dashboard you pick the key under «Billed to key». The default is your own newest active key, otherwise the team's newest. The key must belong to the team and be active, and an IP binding can't be used.
- Via the API the job is billed to the key you call with. It must be a live key (not a
pubkey) with thebatchscope.
If the team has no active key, you can't start a job. Create one under API keys in the dashboard.
Queue and priority
- A team runs one job at a time. If you start more, the others wait in the queue (status
koe) and start automatically in turn. - Enterprise jobs are taken before Pro jobs, and capacity is always reserved for Enterprise.
- How many jobs can be queued or running at once is in the table above.
- Live calls go first. When the API is busy, a running job briefly waits with its next part so your (and others') regular calls don't slow down. Jobs can therefore take longer at busy times. Pro jobs wait at «Busy», Enterprise jobs only at «Very busy» (the same levels as under Usage → Busy times) — so Enterprise feels it later than Pro.
- A job waits at most about 2 minutes per part — after that it runs the next part anyway — and nothing is lost: the job continues by itself when there is room. While it waits, the dashboard shows Waiting for capacity, and the API responds
venter_paa_kapacitet: true.
How long is the result kept?
The result and the input are kept for 7 days (Pro) or 30 days (Enterprise) after the job ended — also when it was cancelled, stopped at the quota or failed. Then they are deleted and the job gets status udloebet. If nobody has downloaded the result, you get a reminder 24 hours before it is deleted.
Next steps
- File format for jobs — exactly what the file should look like
- Follow a job and download the result
- When a job fails — error codes
- Jobs via the API