Numbeo Data Without the Paid API: Cost-of-Living Exports 2026

Numbeo is the most-cited crowd-sourced cost-of-living database on the web — rent, groceries, restaurants, transport, utilities, and the composite indices that relocation calculators and “is City X expensive” articles all quote. If you want that data programmatically, Numbeo does have an API. The catch is that it’s a paid commercial license, not a free developer tier: access is sold per use case, the terms restrict redistribution, and for a researcher, a relocation tool builder, or an analyst doing a one-off study, the licensing overhead is disproportionate to the need. The good news is that the exact same indices Numbeo would sell you through the API are already published in plain HTML tables on the public city pages. This guide covers how to export Numbeo cost-of-living data without the paid API in 2026.

Why the API is a paid license, not a free tier

Numbeo’s data is its product. The site is free to read, but programmatic access is monetized through a commercial API license with negotiated terms — it’s aimed at companies embedding the data into products, and the agreement governs caching and redistribution. There is no self-serve free key for ad-hoc analysis.

For most people the friction isn’t even the price — it’s the contract. A grad student doing a regional cost study, or an engineer prototyping a relocation calculator, doesn’t want a redistribution agreement; they want a CSV. And since the public city pages render the identical indices in HTML, the public surface is the obvious Numbeo API alternative.

What data is actually available

The public cost-of-living page for any city (numbeo.com/cost-of-living/in/<City>) exposes the full table the API would return:

• Composite indices: Cost of Living Index, Rent Index, Cost of Living Plus Rent, Groceries Index, Restaurant Price Index, Local Purchasing Power Index (all normalized to a reference baseline).
• Itemized prices: a long table of individual line items — meal at an inexpensive restaurant, milk, bread, monthly transit pass, utilities for an 85m² apartment, internet, a pair of jeans, one-bedroom rent in/out of center, and so on — each with an average and a typical range.
• Contributor metadata: the number of data points / contributors and a last-updated indicator, which tells you how fresh and well-sampled a city is.

There are sibling pages with the same structure for property prices, quality of life, crime, and healthcare indices if you need those dimensions too.

How the public surface works

This is one of the gentler targets on the open web:

• Server-rendered HTML tables. The indices and itemized prices live in standard <table> markup. No GraphQL, no heavy client app, no embedded-JSON spelunking required — you parse the table rows directly. Each row gives an item label, an average value, and a low–high range.
• Predictable URLs. City pages follow cost-of-living/in/<City-Name> with a city slug; country and region rollups and the cross-city comparison pages follow equally regular patterns. That makes a multi-city export a simple matter of iterating a city list.
• Currency parameter. Prices can be requested in different currencies via a query parameter, so you can normalize an entire export to one currency at fetch time.

The crawl shape is trivial: build a list of city slugs → fetch each page → parse the index block and the itemized price table → emit rows.

Rate limits and how to live with them

There’s no published quota for the public pages, but be a good citizen — this is crowd-sourced data on a modest-traffic site:

• Keep concurrency low and add a small delay between requests. There’s no reason to hammer it.
• The data updates slowly (it’s an aggregate of contributions over months), so cache hard and refresh monthly or quarterly, not daily.
• For a global export across hundreds of cities, pace the run and rotate IPs if needed, but you rarely need heavy infrastructure here.
• Capture the contributor count so you can filter out thin, low-confidence cities downstream.

A clean output schema

Normalize each city into an indices block plus the itemized prices:

{
  "city": "Lisbon",
  "country": "Portugal",
  "currency": "EUR",
  "indices": {
    "cost_of_living_index": 47.2,
    "rent_index": 31.8,
    "cost_of_living_plus_rent_index": 39.9,
    "groceries_index": 41.0,
    "restaurant_price_index": 45.6,
    "local_purchasing_power_index": 58.3
  },
  "prices": [
    { "item": "Meal, inexpensive restaurant", "avg": 12.0, "low": 9.0, "high": 15.0, "unit": "meal" },
    { "item": "Milk (1 liter)", "avg": 0.92, "low": 0.70, "high": 1.20, "unit": "liter" },
    { "item": "Apartment (1 bedroom) in city centre", "avg": 1150, "low": 900, "high": 1400, "unit": "month" }
  ],
  "data_points": 4821,
  "last_updated": "2026-05",
  "scraped_at": "2026-06-06T12:00:00Z"
}

Key on city + country and keep data_points so consumers can weight or exclude under-sampled cities.

▶ Try the Numbeo Cost of Living Scraper on Apify — composite indices and the full itemized price table for any city, normalized to one currency. No paid API license required.

Use cases

• Relocation and salary calculators — power “how much do I need to earn in City B to match City A” tools.
• Cost-of-living research — academic and journalistic studies comparing regions over time.
• HR and compensation — geographic pay-adjustment models for remote teams.
• Travel content — “cheapest cities for digital nomads” rankings built from real indices.
• Real-estate and investment context — pair rent indices with property data for market screens.

Build it yourself vs. a managed actor

This is one of the more DIY-friendly targets — it’s plain HTML tables. A simple script gets you one city quickly. The work that adds up is breadth and consistency: building and maintaining the city list, currency normalization, handling cities with sparse data, parsing the range strings reliably, and absorbing the occasional table-markup tweak. Across hundreds of cities that’s real glue code.

A managed actor maintains the city list and table parsing and hands you normalized rows for any city set. For one or two cities, write the script; for a multi-country export or a recurring refresh, the managed actor is the cleaner Numbeo API alternative.

Common pitfalls

• Index baseline confusion — Numbeo indices are relative to a reference baseline, not absolute money. Don’t read “cost of living index 47” as a price. Capture the indices and the itemized prices separately.
• Currency leakage — pin the currency parameter, or a multi-city export ends up mixing currencies.
• Range parsing — each line item has an average and a low–high range; parse all three, not just the average.
• Thin cities — small towns may have a handful of contributors and noisy numbers. Use data_points to filter.
• Freshness — the last-updated marker matters; a city updated long ago is less reliable. Store it.

Wrapping up

Numbeo’s API is a paid commercial license with redistribution terms, which is overkill for most research and prototyping. Exporting Numbeo data without the API means parsing the public city pages, where the identical composite indices and itemized price tables sit in plain HTML — a genuinely easy surface to work with. For a city or two, a quick script does it; for a multi-country, recurring export, a managed scraper is the cleaner path to the same cost-of-living data.

▶ Open the Numbeo Cost of Living Scraper on Apify — license-free cost-of-living exports across any city set, normalized and ready for analysis. Pay per result.