DEV Community: Loukas Tzekos

Find remote jobs where the employer actually said "remote" (Python, 20 lines)

Loukas Tzekos — Fri, 23 Oct 2026 14:00:18 +0000

Most job data marks a job "remote" because a model guessed it from the text. Sometimes that's right. Often it's "hybrid, 3 days in Munich". Here's how to get only the jobs where the employer itself published "remote", using Job Opportunities API (JOA). Every field in JOA says whether it was published by the employer or inferred by us, in field_sources.

1. Get a free key (no card): https://jobopportunitiesapi.org/login

2. The script

import os, datetime, requests

API = "https://api.jobopportunitiesapi.org/v1/jobs"
api_key = os.environ.get("JOA_API_KEY")  # free key: https://jobopportunitiesapi.org/login

params = {
    "title": "data engineer",
    "country": "DE",
    "remote": "remote",
    "remote_confirmed": "true",          # only jobs where the EMPLOYER said "remote"
    "posted_after": (datetime.date.today() - datetime.timedelta(days=7)).isoformat(),
    "limit": 20,
}
r = requests.get(API, params=params, headers={"Authorization": "Bearer " + api_key}, timeout=30)
r.raise_for_status()

for job in r.json()["data"]:
    src = job["field_sources"]
    print(f'{job["title"]} | {job["company"]} | remote ({src["remote"]}) | {job["apply_url"]}')

3. Run it

Put your key in an environment variable called JOA_API_KEY, then run python remote_jobs.py.

Real output from today:

Senior Scientific Data Engineer | TetraScience | remote (published) | https://apply.workable.com/j/CD8C2AFA42/apply
Senior Data Engineer (m/w/d) | Device Insight | remote (published) | https://device-insight.breezy.hr/p/2e7513bb4c5e01-senior-data-engineer-m-w-d

Every link goes to the employer's own application page, not a job board.

What changed vs. a normal search
remote_confirmed=true drops every job where "remote" was only inferred. Drop that line and you get more results, each labelled inferred or published, so you can decide yourself.

Ideas

Run it daily with cron and send the list to Slack or email.
Swap title and country for your stack and market.
Add has_salary=true to keep only jobs where the employer published a salary.

What filter do you wish job sites had?

17,651 subdomains, one server: what checking "is this job still open?" taught us

Loukas Tzekos — Tue, 20 Oct 2026 03:34:46 +0000

I run Job Opportunities API (JOA), a jobs API that only reads employers' own career sites and applicant-tracking systems. The hard part is not finding jobs. It is knowing when a job is gone.

Why closing jobs matters
A job board full of dead listings wastes everyone's time. So every job we serve gets re-checked at its source, and when the employer removes it, it leaves the live list and moves to a separate closed list with a date and a reason (for example expired_upstream). Our job pages for closed roles answer HTTP 410, not a soft "sorry".

The rule we thought was enough
Our checker is polite per host: one request per second, back off on 429, respect robots.txt, an honest User-Agent. Per host.

What actually happened
Last night our own data-quality review noticed a spike of "slow down" (429) answers. 90% came from one vendor. Many small employers use an applicant-tracking system that gives each company its own subdomain. We had 17,651 of those subdomains, and every one was its own "host" to our pacer. One request per second each looked polite. But they all sit behind one edge, so the vendor saw 3 to 8 requests per second from us. Polite per host, rude per server.

The fix
We now group hosts into lanes by the server that actually answers, not by the hostname. Shared-edge vendors get one lane, one budget, one penalty box. For this vendor that means one request per second in total, and a full re-check takes about 11.6 hours, still inside our 18-hour target.

The second bug it exposed
A "blocked" answer was counted as a strike against the job, the same as "gone". Blocked never closes a job on its own, but enough blocked strikes plus one real "gone" could have closed a live job. We reset those strikes and are giving "gone" its own counter. Nothing was closed by mistake, but it was closer than I like.

Lessons, if you crawl anything at scale

Rate-limit by the server you hit, not the name you typed.
A 429 is information about the whole vendor, not one page.
"We couldn't check" and "it's gone" are different answers. Store them differently.

If you want to see how a job's status is exposed, /v1/jobs?status=closed returns the closed list with closed_at and closed_reason. Free key, no card: https://jobopportunitiesapi.org

What's the worst rate-limit surprise you've hit?

Teaching small models to read job postings: our arena and the JOA Small, Advance and Deep fine-tunes

Loukas Tzekos — Thu, 08 Oct 2026 12:00:00 +0000

Disclosure: Job Opportunities API (JOA, jobopportunitiesapi.org) is an independent data business that sells API access to job-posting data. AI helped run the experiments, check the numbers and draft this text; Loukas (Luca) Tzekos is editorially responsible. Contact: hello@jobopportunitiesapi.org.

The problem

Job Opportunities API (JOA) collects job postings from employers' own recruiting systems and careers pages and re-checks them every day. A posting arrives as a page of text written by the employer. Our customers want fields: the title, the company, where the job is, the pay and its period, the seniority, whether it is remote, when it was posted and whether the poster is the employer or a staffing agency.

Large models do this well, but running one over every posting, every day, is slow and expensive, and the best of them reason for thousands of tokens per posting. We wanted to know whether a small model trained for this one task could do as well. To answer that honestly we first needed a fair test.

The arena

The arena is 250 real job listings from JOA, 11 fields each: title, company, location, salary currency, minimum, maximum and period, seniority, remote type, posted date, and agency or not.

Same input for every model: the same prefetched page text and structured data, and up to 24,000 tokens to answer. A reply cut off mid-thought counts as no answer.
Reference labels were built with Claude Opus agents that read our stored text and the live page, with a confidence level per field.
Two judges, Kimi-Linear-48B and Seed-OSS-36B, graded every answer field by field; a cell scores the mean of the two.
What counts: the main rule leaves out values that appear nowhere in the model's input; a missing answer where the value could be found scores 0.
Uncertainty: every score has a 95% range from a paired bootstrap over listings. Re-running one model moved its score by up to 1.5 points, so smaller gaps are noise.

By 25 September 2026, 68 open-weight models and their quantised variants had run it. The leader, Qwen3.5-27B, scored 89.2, with ten others statistically tied, up to a 235-billion-parameter model. Reasoning models scored higher but spent thousands of tokens per listing, and size was not destiny: granite-3.3-8b-instruct scored 86.4, close to models many times its size.

The fine-tunes

Qwen3.5-27B became the trainer. It extracted the same fields from a large set of JOA listings, and a refinement step kept only answers grounded in the text (a title or a salary that actually appears in the posting) while keeping the original share of agency postings and empty fields. None of the 250 arena listings was in the training data, and the Claude-built reference labels were used only to evaluate, never to train.

We trained LoRA adapters on three open base models:

Name	Base model (licence)
JOA Small	ibm-granite/granite-4.2-3b (Apache 2.0)
JOA Advance	ibm-granite/granite-3.3-8b-instruct (Apache 2.0)
JOA Deep	Qwen/Qwen3.8-27B (Apache 2.0)

Results

Arena, 84 models, graded 29 September (Advance) and 2 October 2026 (Small, Deep):

Rank	Model	Score	95% range	Median tokens per answer
1	JOA Small	93.3	92.2–94.4	117
2	JOA Advance	92.7	91.6–93.9	123
3	JOA Deep	92.2	91.0–93.4	111
4	Trainer, Qwen3.5-27B	89.2	86.9–91.4	2,946
71	Stock granite-4.2-3b	64.5	59.7–69.0	4,411

Three things we did not expect:

The smallest model ranks first. Fine-tuning lifted granite-4.2-3b from rank 71 to rank 1. Small and Advance are statistically tied; Deep is just behind. Once the task was learned, size stopped mattering on this test.
The students beat their teacher. Partly because the trainer sometimes reasoned until it ran out of tokens, and partly because the training answers were tidied into one consistent form. On the listings the trainer did answer, Advance was still 1.9 points ahead (95% range +0.5 to +3.5).
They answer in about 110–120 tokens. The trainer needs about 2,900, almost all of it reasoning.

A second, stricter test used 250 different, recent listings, each verified twice by Claude Opus against the live page and the application flow. On exact match, all three fine-tunes scored about 85%, the trainer about 86% and the stock base models 71–82% (2 October 2026). Here the teacher is still slightly ahead.

Limits

They read what we store, not the live page. Our stored text is usually the description body; the header, where the title, location and posted date often sit, can be missing.
They cannot tell that a job has closed. From stored text alone, all three called a few dead listings open. The fix is better input, not a bigger model.
JOA Deep is weak on posted date (72, against 89 for JOA Small).
JOA Small cannot drive a tool-using agent. It works when given the input, not when asked to fetch it.
The references and the judges are models. Two judges, checked references and confidence ranges reduce that risk; they do not remove it.

Status and what is next

No weights are published yet; the three model pages are status pages. JOA Small runs on a single consumer graphics card, which makes it the candidate for everyday use. Next we will feed the models a richer input (the rendered page, structured data and the recruiting system's own data), fix the posted-date weakness, re-run both tests and then decide what to release.

Arena dataset: https://huggingface.co/datasets/JobOpportunitiesAPI/joa-extraction-arena
Model status pages: https://huggingface.co/JobOpportunitiesAPI/joa-small, https://huggingface.co/JobOpportunitiesAPI/joa-advance, https://huggingface.co/JobOpportunitiesAPI/joa-deep
JOA Job Market Report, September 2026: https://jobopportunitiesapi.org/reports/job-market-september-2026
Job Opportunities API (JOA): https://jobopportunitiesapi.org

This work used the EuroHPC supercomputer Discoverer+ in Bulgaria, made available by the EuroHPC Joint Undertaking through an AI Factories Playground access allocation (project EHPC-AIF-2026PG01-1124).

Contact. General: hello@jobopportunitiesapi.org · Legal matters: luca@tzekos.eu · Phone: +30 2311 113 603. Job Opportunities API (JOA) is a sole proprietorship of Loukas Tzekos, Didaskalisis Papathanasiou Vas. 79, 54629 Thessaloniki, Greece. VAT EL117613696.

Austrian job postings are about four times as likely as German ones to state pay. Here is how we checked.

Loukas Tzekos — Tue, 06 Oct 2026 13:39:46 +0000

Disclosure: written by Job Opportunities API (JOA, jobopportunitiesapi.org), an independent data business that sells job-posting data through an API. AI helped write and check the analysis and this text; Loukas (Luca) Tzekos is editorially responsible. Contact: hello@jobopportunitiesapi.org.

Austria has required job adverts to state a minimum pay since 2011. Germany has no such rule. We asked our own data how that shows up in practice, then tested our own measurement before publishing. The full report, with every table, is at https://jobopportunitiesapi.org/reports/job-market-september-2026 and comes with a free CSV, a Markdown version and an audio edition of about 46 minutes (synthetic voice).

The data

Job Opportunities API (JOA) reads job postings from employers' own recruiting systems and careers pages and re-checks each one daily. On 4 October 2026 that was a snapshot of 2,111,453 open postings from 144,098 employers. The report analyses the 1,385,899 located in North America (986,641) and Europe (399,258). The report compares them with official vacancy statistics in 14 countries, and across the 51 US jurisdictions their distribution follows the official JOLTS openings (rank correlation 0.96). Read everything below as a description of JOA's own postings.

Austria and Germany

JOA's automated reading detected a pay figure in 33.7% of 7,666 open Austrian postings and in 4.9% of 117,969 German ones, a ratio of 6.9 to 1. The gap holds inside every recruiting system with at least 150 Austrian postings, so the mix of software does not explain it.

Automated detection reads only part of what postings say, so we measured the rest. Two AI agents with web access read stratified random samples of 84 Austrian and 100 German postings, blind to our flags, on the live page where it was still open and otherwise from stored text. A script checked each quoted passage against the text. A second, rule-based detector agreed with the readers on 97.6% of Austrian and 91.0% of German postings.

How we checked ourselves

The sample showed where detection falls short: compound words, amounts written in unusual formats, and figures that appear on the live page outside the stored description. Where our system had detected pay, readers confirmed it in 28 of 28 Austrian and 24 of 29 German postings. Weighted to the full population, the estimate of postings that state pay is 78% in Austria (95% interval 70% to 86%) and 18% in Germany (13% to 26%).

So the headline is: Austrian postings are about four times as likely as German ones to state a pay figure, 4.4 to 1 on the sampled estimate (interval 2.9 to 6.2). The intervals reflect sampling and clustering by employer, and the readers are AI agents. Austria's rule requires the collective-agreement minimum, and about 38% of the amounts we read from Austrian text are that minimum, so we publish whether pay is present and no pay levels. The same checks put the share of postings located in another country than coded at 6.0% for Germany and about 6% for Austria.

A similar question in the United States

In the United States, 24.4% of own-site postings in the 10 jurisdictions with a pay-range posting law have pay detected in a structured field, against 18.7% in 28 states without one (both are lower bounds: detection misses some stated pay).

That is an association, and states differ in other ways: national employers often publish one posting for all states, and laws differ in thresholds and exemptions. Pennsylvania, with no law found, reaches 27.2%; Illinois, with a law, 19.5%. Research with other data puts the effect of such laws at about 30 percentage points, a different quantity from this cross-section.

Read the Methodology

Job boards, aggregators, employer-direct data and official statistics measure different things: boards can count the same vacancy across several portals, official surveys count vacancies at all employers, and JOA counts what employers publish on their own systems. The Methodology section of the report sets out the differences and how to compare them.

Take it further

Detected pay is detection; it says nothing on whether an employer follows a law.
A blind sample of your own data is a cheap way to find what a parser misses.
Say what the source is: here, employer-direct postings that JOA serves.

All aggregates are free under CC BY 4.0: https://jobopportunitiesapi.org/reports/job-market-september-2026/joa-job-market-2026-09.csv. The tables also have a citable record with a DOI: https://doi.org/10.5281/zenodo.23143502. Spot an error? Write to hello@jobopportunitiesapi.org with the subject "Market report correction".

About the data. Job Opportunities API (JOA, jobopportunitiesapi.org) is an independent data business that sells API access to job-posting data. It collects postings from employers' own recruiting systems and careers pages and from a few public employment service feeds, re-checks them daily and honours employer opt-outs. The September 2026 report analyses the 1,385,899 open employer-direct postings located in North America (986,641) and Europe (399,258), from a snapshot of 2,111,453 postings by 144,098 employers on 4 October 2026, and compares them with official vacancy statistics. The report and its data are free to reuse (CC BY 4.0). AI helped write and check the analysis; Loukas (Luca) Tzekos is editorially responsible. Contact: hello@jobopportunitiesapi.org

Track which companies are hiring (and closing roles) with a jobs API

Loukas Tzekos — Sat, 03 Oct 2026 01:16:17 +0000

Disclosure: I build JOA, the jobs API used below. The code runs on its free plan and I tested it against the live API in early October 2026.

Counting live job postings is easy. Knowing which companies are hiring more and which roles just disappeared is more interesting, and most job feeds can't tell you the second part because a closed role simply vanishes.

The Job Opportunities API keeps postings after they leave their source, with a closure date and a reason. This post builds a small hiring tracker on top of that:

a daily snapshot of each company's open-role count (so you can see movement over time),
the roles posted in the last week,
the roles that closed in the last week, with the closure reason,
a rough "days listed" figure that is honest about where it came from.

If you have not used the API before, the first post in this pair covers getting a key, the client basics and pagination. This one builds on it. It uses three endpoints that work on the free Explore plan: /v1/companies/{slug}, /v1/jobs and /v1/jobs/closed. (Get a free key at /login, no card; the key goes in JOA_API_KEY.)

What "closed" means here

Each closed row has closed_at and closed_reason. The documentation is explicit about the reasons:

expired_upstream: the ledger proved the vacancy dead (re-checked against the board listing or the job URL itself).
not_seen: the role stopped appearing at its source for the grace period. Usually a closure, occasionally a careers site that broke.
employer_closed / deadline_passed: stated by the employer itself, for roles listed through Erioun for Teams.

A role an employer merely paused or unlisted is not a closure. Keep that in mind: a closure means "gone from the source", not "filled".

The tracker

Save as hiring_tracker.py (only requests and the standard library):

"""Hiring tracker: which companies are hiring, and which roles are closing.

Runs on the free JOA Explore plan. Needs: Python 3.9+, `pip install requests`, key in JOA_API_KEY.
Each run spends: 1 record per company (the snapshot) + the rows you read from the two lists.
"""
import os
import random
import sqlite3
import statistics
import sys
import time
from datetime import date, datetime, timedelta, timezone

import requests

API = "https://api.jobopportunitiesapi.org"
WATCHLIST = ["spotify", "adyen", "zalando", "n26"]  # company slugs, see /v1/companies?q=
WINDOW_DAYS = 7
SAMPLE = int(os.environ.get("SAMPLE", "10"))  # rows read per list per company = records spent

session = requests.Session()
session.headers["Authorization"] = f"Bearer {os.environ['JOA_API_KEY']}"


def get(path, **params):
    for attempt in range(4):
        resp = session.get(API + path, params=params, timeout=30)
        if resp.status_code in (429, 503):
            time.sleep(int(resp.headers.get("Retry-After", 2 ** attempt)) + random.random())
            continue
        if resp.status_code == 402:
            sys.exit("This month's free records are spent. Wait for the 1st or upgrade.")
        if not resp.ok:
            sys.exit(f"{resp.status_code} {resp.json().get('message', resp.text)}")
        return resp
    sys.exit("Still rate limited after 4 tries.")


def ts(value):
    return datetime.fromisoformat(value.replace("Z", "+00:00"))


db = sqlite3.connect("hiring.db")
db.execute(
    "CREATE TABLE IF NOT EXISTS snapshot ("
    " day TEXT, slug TEXT, open_roles INTEGER, PRIMARY KEY (day, slug))"
)


def snapshot(slug):
    """Today's open-role count for one company (1 record), stored so tomorrow can diff against it."""
    company = get(f"/v1/companies/{slug}").json()["data"]
    today = date.today().isoformat()
    previous = db.execute(
        "SELECT day, open_roles FROM snapshot WHERE slug=? AND day<? ORDER BY day DESC LIMIT 1",
        (slug, today),
    ).fetchone()
    db.execute("INSERT OR REPLACE INTO snapshot VALUES (?,?,?)", (today, slug, company["open_roles"]))
    db.commit()
    return company, previous


def days_listed(job):
    """Whole days between the posting and its closure.

    Use the employer's own posted_at when the field is 'published'; otherwise fall back to
    first_seen_at (when the ledger first saw it), which can only under-count.
    """
    start = job["posted_at"] if job["field_sources"].get("posted_at") == "published" else job["first_seen_at"]
    return max((ts(job["closed_at"]) - ts(start)).days, 0)


def report(slug):
    since = (datetime.now(timezone.utc) - timedelta(days=WINDOW_DAYS)).strftime("%Y-%m-%dT%H:%M:%SZ")
    company, previous = snapshot(slug)
    now = company["open_roles"]
    delta = f"{now - previous[1]:+d} since {previous[0]}" if previous else "first snapshot, no comparison yet"
    print(f"\n{company['name']}: {now} open roles ({delta})")

    fresh = get("/v1/jobs", company=slug, posted_after=since, limit=SAMPLE).json()
    more = "+" if fresh["has_more"] else ""
    print(f"  posted in the last {WINDOW_DAYS} days: {len(fresh['data'])}{more}")
    for job in fresh["data"][:3]:
        print(f"    + {job['title'][:60]}")

    closed = get("/v1/jobs/closed", company=slug, closed_after=since, limit=SAMPLE).json()
    more = "+" if closed["has_more"] else ""
    print(f"  closed in the last {WINDOW_DAYS} days: {len(closed['data'])}{more}")
    for job in closed["data"][:3]:
        print(f"    - {job['title'][:52]}  [{job['closed_reason']}, listed ~{days_listed(job)}d]")
    if closed["data"]:
        median = statistics.median(days_listed(j) for j in closed["data"])
        print(f"  median days listed (sample of {len(closed['data'])}): {median}")


if __name__ == "__main__":
    for slug in WATCHLIST:
        report(slug)
    spent = get("/v1/me").json()
    print(f"\nplan={spent['plan']}")

Find slugs with /v1/companies?q=<name>. The ones above are real company slugs in the ledger.

Real output

spotify: 84 open roles (first snapshot, no comparison yet)
  posted in the last 7 days: 9
    + Partner Manager - Lifestyle & Wellness
    + Program Manager - Podcast Sales Strategy & Solutions
    + Senior Software Engineer
  closed in the last 7 days: 10+
    - Security Engineer - Detection and Response  [not_seen, listed ~7d]
    - C++ Engineer - Experience  [not_seen, listed ~27d]
    - Marketing Technology Manager  [not_seen, listed ~75d]
  median days listed (sample of 10): 28.0

Adyen: 68 open roles (first snapshot, no comparison yet)
  posted in the last 7 days: 10+
    + Team Lead - Technical Support
    + Finance Support Specialist
    + Implementation Engineer
  closed in the last 7 days: 10+
    - Senior System Administrator [Storage Engineer]  [not_seen, listed ~127d]
    - Account Manager  [not_seen, listed ~318d]
    - Senior System Administrator [Ceph Engineer]  [not_seen, listed ~127d]
  median days listed (sample of 10): 78.5

Zalando: 93 open roles (first snapshot, no comparison yet)
  posted in the last 7 days: 2
    + Senior Applied Scientist (all genders)
    + Prozessmanager (all genders) Warehouse Operations Lahr
  closed in the last 7 days: 10+
    - Senior ML Software Engineer - Growth & Lifecycle / L  [not_seen, listed ~65d]
    - Creator Manager - Sports (all genders)  [not_seen, listed ~45d]
    - Senior Principal Product Manager – Client Foundation  [not_seen, listed ~89d]
  median days listed (sample of 10): 59.5

N26: 45 open roles (first snapshot, no comparison yet)
  posted in the last 7 days: 9
    + Head of Business Internal Audit
    + Senior Associate Audit & Operations
    + Steuerberater (Tax Manager)
  closed in the last 7 days: 10+
    - Backend Engineer - Investments & Savings  [not_seen, listed ~98d]
    - Senior Cloud Security Engineer  [not_seen, listed ~67d]
    - iOS Engineer - Digital Identity  [not_seen, listed ~56d]
  median days listed (sample of 10): 42.0

plan=explore

(A 10+ means the sample cap was hit. Raise SAMPLE if you want more rows and have the records to spend.)

Details that make it more honest

Days listed uses provenance. Every row carries field_sources. When posted_at is published, the employer's own date is used. Otherwise the code falls back to first_seen_at (when the ledger first saw the role), which can only under-count. The fallback is stated in the docstring so nobody mistakes the median for a measured time-to-fill. It is a rough indicator over a sample, nothing more.

The delta column needs a second day. The first run has nothing to compare against, so it says so. To check the diff logic, I edited a snapshot row for yesterday by hand and re-ran: the output read 84 open roles (+4 since <yesterday>). From the second real day on, you get the movement for free.

Staying inside the free allowance

On Explore, one row returned is one record, and the allowance is 1,000 a month. With four companies and SAMPLE=10, one run costs at most 4 x (1 + 10 + 10) = 84 records, so a weekly run uses roughly a third of the month. The key lever is SAMPLE: reading three rows instead of ten per list makes a run a handful of records. /v1/me shows your usage and costs nothing.

Schedule it with cron:

0 7 * * 1  cd /home/me/tracker && JOA_API_KEY=... python3 hiring_tracker.py >> weekly.txt

Limits to be upfront about

Closure is evidence, not proof of a filled role. Companies close and repost roles all the time.
not_seen can occasionally mean a company's careers page was down. Look at several closures at one company before reading anything into it.
Coverage differs by country and by how an employer publishes jobs. Check the facts page for the markets you care about.

If you outgrow it

Re-querying works fine for a small watchlist. If you track many companies, the delta feed (/v1/changes) returns only what changed since your last call (created, updated, withdrawn, delisted), so you stop paying records to re-read unchanged rows. It is on the Growth plan and up, see pricing. There is also a keyless, beta /public/companies/{slug}/open-roles-history endpoint with a daily open-roles series per company. The history only started recently, so treat it as thin for now.

If you build something with this, or find a number that looks wrong, tell me in the comments.

Get European job postings from an API in Python in 5 minutes

Loukas Tzekos — Fri, 02 Oct 2026 23:05:50 +0000

Disclosure: I build JOA, the jobs API used below. Everything here works on its free plan, and I ran every snippet against the live API in early October 2026 before writing this.

If you have ever needed European job postings as data (for a dashboard, a research project, a job board, or just to see what a market looks like), you know the usual options: scrape career pages yourself, or buy a feed that is a mix of aggregator copies.

This post uses the Job Opportunities API (JOA), which serves postings taken from employers' own career sites and applicant-tracking systems. We will write a small Python client that:

authenticates with a free key,
filters by country, remote status and recent date,
pages through results with the API's cursor,
uses the per-field provenance tags to ask for salaries the employer actually published,
writes a CSV, and
stays inside the free record allowance.

Step 0 - look before you sign up

The statistics endpoints need no key and no account. This gives you the shape of the data (coverage per country, freshness, which sources feed it):

curl https://api.jobopportunitiesapi.org/public/coverage
curl https://api.jobopportunitiesapi.org/public/coverage/countries

Coverage is not uniform across countries, and the report says so openly, so check the countries you care about before building on them. The numbers are live, which is why I am not quoting any here: the always-current version is on the facts page.

Step 1 - get a free key

Sign in with your email at jobopportunitiesapi.org/login, click the link it sends, and press Create a free key on the dashboard. There is no password and no card. The free Explore plan has a monthly record allowance rather than a trial period, so it does not expire (plans and limits).

export JOA_API_KEY='paste-your-key-here'
curl -s -H "Authorization: Bearer $JOA_API_KEY" https://api.jobopportunitiesapi.org/v1/me

/v1/me tells you the plan, the rate limits and today's usage, and it costs no records. Useful to know early: one row returned = one record, so while exploring, keep limit small.

Step 2 - the client

Save this as joa_europe_jobs.py (it needs only requests):

"""Pull European job postings from the Job Opportunities API (JOA) with Python.

Needs: Python 3.9+, `pip install requests`, and a free Explore key in JOA_API_KEY.
"""
import csv
import os
import random
import sys
import time
from datetime import date, timedelta

import requests

API = "https://api.jobopportunitiesapi.org"
# EU27 + EFTA + UK as ISO-3166 alpha-2 codes; the API accepts a comma-separated list.
EUROPE = (
    "AT,BE,BG,HR,CY,CZ,DK,EE,FI,FR,DE,GR,HU,IE,IT,LV,LT,LU,MT,NL,PL,PT,RO,SK,SI,ES,SE,"
    "IS,LI,NO,CH,GB"
)

session = requests.Session()
session.headers["Authorization"] = f"Bearer {os.environ['JOA_API_KEY']}"
session.headers["Accept"] = "application/json"


def get(path, **params):
    """GET with the retry rule from the docs: retry 429/503 after Retry-After, never retry 402."""
    for attempt in range(4):
        resp = session.get(API + path, params=params, timeout=30)
        if resp.status_code in (429, 503):
            wait = int(resp.headers.get("Retry-After", 2 ** attempt))
            time.sleep(wait + random.random())  # jitter
            continue
        if resp.status_code == 402:
            sys.exit("This month's free records are spent. Wait for the 1st or upgrade.")
        if not resp.ok:  # the API explains itself: {"error": ..., "message": ...}
            sys.exit(f"{resp.status_code} {resp.json().get('message', resp.text)}")
        return resp
    sys.exit("Still rate limited after 4 tries.")


def iter_jobs(max_rows=25, page_size=25, **filters):
    """Walk /v1/jobs with the keyset cursor, stopping after max_rows (each row is one record)."""
    cursor, seen = None, 0
    while seen < max_rows:
        params = dict(filters, limit=min(page_size, max_rows - seen))
        if cursor:
            params["cursor"] = cursor
        resp = get("/v1/jobs", **params)
        body = resp.json()
        for job in body["data"]:
            yield job
            seen += 1
        if not body["has_more"]:
            break
        cursor = body["next_cursor"]
    left = resp.headers.get("x-ratelimit-records-remaining")
    print(f"  (records left this month: {left})", file=sys.stderr)


def provenance(job, field):
    """Where did this field come from? published / inferred / absent."""
    return job["field_sources"].get(field, "absent")


if __name__ == "__main__":
    me = get("/v1/me").json()  # costs no records
    print(f"plan={me['plan']} per_minute={me['limits']['per_minute']} per_day={me['limits']['per_day']}")

    week_ago = (date.today() - timedelta(days=7)).isoformat()

    print("\n== Remote data-engineering roles in Europe, last 7 days ==")
    rows = []
    for job in iter_jobs(
        max_rows=10,
        country=EUROPE,
        remote="remote",
        title="data engineer",
        posted_after=week_ago,
    ):
        rows.append(job)
        print(f"{job['country']}  {job['title'][:48]:<48}  {job['company'][:28]:<28}  "
              f"remote={provenance(job, 'remote')}")

    print("\n== Roles where the employer itself published the salary ==")
    for job in iter_jobs(
        max_rows=6,
        country="DE,FR,NL,IE,ES,IT",
        has_salary="true",
        require_fields="salary",
        title="engineer",
    ):
        lo, hi = job["salary_min"], job["salary_max"]
        print(f"{job['country']}  {job['title'][:44]:<44}  {lo}-{hi} {job['salary_currency']}/{job['salary_period']}")

    with open("european_jobs.csv", "w", newline="", encoding="utf-8") as fh:
        writer = csv.writer(fh)
        writer.writerow(["title", "company", "country", "city", "remote", "posted_at", "apply_url"])
        for job in rows:
            writer.writerow([job["title"], job["company"], job["country"], job.get("city", ""),
                             job["remote"], job["posted_at"], job["apply_url"]])
    print(f"\nwrote european_jobs.csv with {len(rows)} rows")

A few choices worth explaining:

Cursor pagination. /v1/jobs is keyset-paginated: every response carries next_cursor and has_more, and you pass the cursor back. There are no offsets, so rows that appear while you page can't shift your window.
Retries follow the docs. Retry 429 and 503 after Retry-After (with jitter), and never retry 402, which means the month's records are spent.
Errors explain themselves. The API replies with {"error": ..., "message": ...}, and the client prints the message. I found this out the hard way, see the gotcha below.

Step 3 - run it

pip install requests
python joa_europe_jobs.py

This is the real output from my run (yours will differ, since the data moves every day):

plan=explore per_minute=30 per_day=5000

== Remote data-engineering roles in Europe, last 7 days ==
FR  Data Engineer - Transport - Nantes                Sopra Steria                  remote=published
EE  Senior Backend Engineer - Data Core (remote, Eur  Modash                        remote=published
FR  Senior Software Engineer - Data Search (remote,   Modash                        remote=published
HR  Data / DevOps Engineer (m/f)                      solvership                    remote=inferred
DE  Senior Data Platform Engineer (m/w/d) | Snowflak  Jobrad Loop                   remote=inferred
FR  Finance Data Engineer                             Voodoo                        remote=published
FR  Stage - Data Engineer - Aeroline - Toulouse       Sopra Steria                  remote=inferred

== Roles where the employer itself published the salary ==
IT  Field Automation Engineer                     28000-35000 EUR/year
IT  Junior Digital Verification Engineer          35000-40000 EUR/year
DE  QA Engineer (gn)                              55000-75000 EUR/year
IT  SALES ENGINEER (m/f/d)                        43000-50000 EUR/year
IT  PROGRAMMATORE PLC / AUTOMATION SOFTWARE ENGI  35000-45000 EUR/year
IT  Data Engineer – Cloud & AI Solutions          33000-40000 EUR/year

wrote european_jobs.csv with 7 rows

Provenance: why `remote=published` matters

Every row has a field_sources object that tags each field as published (the employer stated it), inferred (derived by the ledger, for example from the title or location) or absent. Look at the first query above: some roles are remote=published, others remote=inferred. If you are building something where a wrong "remote" label is costly, you can now filter on it, and the second query shows the server-side version of the same idea: require_fields=salary returns only rows where the salary came from the employer, not from a guess.

Gotchas I hit while testing

require_fields accepts a fixed set of fields (description, employment_type, location, posted_at, remote, salary, source_type). My first attempt used salary_currency and got a clear 422 bad_require_fields listing the valid ones. That is why the client prints the API's message.
title= searches the job title only. q= searches title, company and location, and description_contains= searches the advert body. Pick the narrowest one.
Structured salaries are a small share of postings in most markets, so a salary-filtered query returns far fewer rows than an unfiltered one. That is expected, not a bug.
This is not a census of every vacancy. Employers with public career pages are better represented than those without.

Where to go next

Roles that have left their source are kept with a closure date and reason: /v1/jobs/closed. I use it in the follow-up post, tracking which companies are hiring and which roles are closing.
If you work with AI agents, there is an MCP connector, so an agent can query the same data without you writing a client.
The full parameter list is generated from the OpenAPI spec: docs.
When 1,000 records a month is not enough, paid plans start at EUR 29/month: pricing.

If you hit a rough edge, tell me in the comments. It is one person's product and I read everything.