The commercial questions are answered on Pricing. These are the ones that come next — from the people who have actually asked them: developers, buyers, researchers, public bodies and banks. Including the ones where the answer is no.
No. We do not offer an SLA, and no plan includes one. If your payroll run cannot proceed without us being reachable at 03:00, do not call us at 03:00.
The design answer is that you should not need one. Calls are unlimited on every plan precisely so you can fetch on a schedule and read from your own store — this data changes on a published monthly cadence, not continuously. A system that caches is unaffected by an outage; a system that polls at the moment of use has made our availability its own.
Enterprise terms are negotiable. Ask before you buy, not after.
The API runs on Hetzner in Helsinki, Finland — inside the EU. Analytics are self-hosted on our own infrastructure in Nuremberg, Germany. Two processors touch anything of yours and they are named on the legal page: Stripe, which holds the billing details we never see, and SMTP2GO, which delivers email.
Your API queries are logged — the jurisdiction, the endpoint, the timestamp — because that is how metered plans are counted and how we answer "why was I charged for that". They are not sold, shared or used to build anything.
/v1 break?developerAdding a field is not a breaking change and we will do it without
warning; removing or renaming one is, and we will not do it inside
v1. If v2 ever exists, v1 keeps
answering.
Write your parser to ignore fields it does not recognise. The
console reconciles against /openapi.json in both
directions, so the schema is the contract.
No SDKs. It is REST with an X-API-Key
header and JSON out — your language's HTTP client is the SDK, and a thin
wrapper we maintain badly is worse than none.
Using your key has working Node and Python in four lines each.
A call takes up to 20 jurisdictions and 400 days. All 241 countries for one year is about 13 calls, not 241 — and CSV export gives you the same rows as a file.
The 400-day cap is not a rate limit. It bounds one response so a five-year request cannot quietly become a fifteen-megabyte one.
Per minute, as abuse protection rather than billing:
Developer 60, Pay per territory and Forty territories 600,
Enterprise 6,000. Exceeding one returns 429 and
never an invoice.
If you are hitting these you are almost certainly not caching.
Two different answers, and conflating them is how people get surprised.
The API answers to 2036. Most closures are rules — Christmas Day, the third Monday in January, the tenth of Muharram — and a rule can be computed as far forward as you like.
We actively maintain the next 36 months. That is the window we review, re-source and correct: where announcements are chased, where errata get raised, and where a date being wrong is our problem. Beyond it, you are reading arithmetic — correct arithmetic, but arithmetic that no authority has confirmed yet, because in most cases no authority has published that far ahead either.
The assurance field is where this shows up rather than
being something you have to remember: far-forward rows are
compiled, and filtering on min_assurance is how
you keep a long horizon and an honest one at the same time.
The static files this site publishes hold a narrower window — 2025 to 2028 — because a public file is what a visitor can retrieve, not what the database can materialise.
This is also why dossiers are reissued every month rather than published once. A dated PDF is only worth what its date is worth: a calendar built in January and still being sold in October has quietly become a document about January. Every dossier is rebuilt from the current corpus on the monthly cadence, carries its edition on the cover, and a standing order receives each one — so freshness is a property of the product rather than a promise about it.
There is no history before 2025. If you need a twenty-year back series for a regression, this is not that dataset and we would rather say so now.
No. We hold 57 exchange calendars — when a market does not trade — and national and subdivision closures. A payment system's value-date calendar is a different instrument published by a different authority, and we do not currently retrieve it.
What that means in practice: use us for is the market open and is the office shut. Do not use us to decide a settlement value date. If you need those calendars, say so — it is the most-asked gap on this list.
Yes. Exchange closures carry a status, and half-days are marked
separately from full closures. Jurisdiction-level records carry
half_day in operational_status too, and the
Operating Calendar has a switch for them.
A half-day is not a day off and not a working day, and collapsing the two is how a cut-off gets missed.
We do not publish a lead-time commitment, because we cannot control when an authority announces.
What we do instead: one-off decrees that no rule predicts land in
/v1/announcements, which is the only endpoint with a reason
to be polled. Editions ship monthly. A correction ships as a new
edition rather than silently replacing the old, and every correction is
published in the errata log — which is
not pruned.
We record jurisdictions, not countries — the authority that declares the closure. That is a deliberately narrower claim: an SAR, an overseas territory and a state are all jurisdictions, and calling them countries would be contested where it is not simply wrong.
Listing a jurisdiction is a statement that some authority publishes closures for it. It is not a position on sovereignty, recognition or status, and nothing in the corpus ranks or scores a place.
Three tiers, on every row. verified — checked against a primary source: a gazette, a statute, a central bank notice. corroborated — two or more independent secondary sources agree; an aggregator agreeing with our own research is one piece of evidence wearing two hats and does not qualify, which is why this tier is small. compiled — one source, or one we could not independently confirm.
Most of the corpus is compiled, and saying so is the
point of the label. Filter with min_assurance=verified if
you only want dates confirmed against an authority. See the
Atlas for the mix per country.
Record GET /v1/health alongside your dates — it returns
the running version and db_mtime, which
together identify the corpus build that answered you. Dossiers carry an
edition on the cover instead.
Calendar API responses do not currently carry an edition string, and there is no DOI. If you need a formally citable, frozen snapshot for a paper, ask — we can cut one, but there is no self-service route today.
You may query it, store the results, and use them to run and build your own products within your plan's scope. Caching is expected.
What needs a separate redistribution licence is republishing the corpus, or a substantial part of it, as a dataset, feed or competing product. The line is not the number of calls — it is whether the output is your product using our data, or our data presented as your product. Figures, tables and quoted dates in a paper are fine; a downloadable appendix that is effectively the corpus is not. The full terms.
Both, and they are different things.
Academic access is free — the full data shape, scoped to your project and renewed yearly, in exchange for a citation naming the edition you used. We are not being generous: a researcher who reads the assurance ladder properly and tells us which row is wrong is worth more than the licence fee. What we ask for →
Non-profits pay 40% of list — the same products, not a cut-down tier, because a small charity is a small customer rather than a different one. The prices →
Both are approved by a person, every time. Separately, the Developer plan is free to anyone — one territory, 60 requests a minute, no card.
Not self-service. Checkout takes a card through Stripe, which is the merchant of record and issues the invoice.
Annual invoicing and PO terms exist on Enterprise and are arranged by conversation. If your finance team cannot pay a card, start there rather than at the checkout button.
Sold through Link, LLC — Stripe's merchant-of-record entity — not Naisu Limited. That is expected: Stripe is the seller for the transaction, charges and remits VAT or sales tax in your country, and issues your invoice. Naisu Limited is not VAT-registered, which is exactly why the arrangement exists.
Naisu Limited publishes and licenses the data, so accuracy, edition and liability terms are ours; payment terms are theirs. You can resend any invoice to yourself from your account.
Capped at the fees paid for the product that gave rise to the claim in the twelve months before it arose. If you paid £99 for a dossier, that is the cap for that dossier. No indirect or consequential loss.
This is worth reading properly rather than assuming: if a wrong date
would cost you six figures, our cap is not your insurance, and you
should treat the assurance field as a control rather than
decoration. The liability clause in full.
There is no escrow arrangement today. We would rather write that than let you assume otherwise.
What reduces the exposure: everything you have queried, you are licensed to keep and store. There is no runtime dependency and no phone-home — a cached corpus keeps working. Dossiers are PDFs you have already downloaded.
Building a product on top of it is exactly what the Calendar API is for. Reselling the corpus itself, or presenting our data as your dataset, needs a redistribution licence — see above, and ask.
Almost none. We hold an email address per account, a hash of each API key — never the key — and usage records. We never see a card: Stripe holds billing details and we hold a customer reference.
The corpus itself is public-authority data about dates and contains no personal data at all.
No, none of them. If a certification is a hard procurement gate, we do not currently clear it and you should know that before a bid, not during one.
What exists instead is checkable: keys stored as hashes, sessions with an absolute expiry, no card data on our infrastructure, EU hosting, two named subprocessors, and a published errata log. A due-diligence questionnaire will be answered honestly and quickly.
The public pages and the Operating Calendar are built to WCAG 2.1 AA and audited against it — contrast, keyboard operation, focus visibility, reflow to 320px, and semantic tables. Findings are fixed as they are found rather than logged for later.
There is no formal published accessibility statement or third-party audit certificate yet. If you need one for a procurement pack, ask.
Editions are immutable and a correction ships as a new edition, so
the edition you cited stays retrievable. Record version and
db_mtime from /v1/health at the time you
query, and the errata log records what changed and when.
There is no per-account query archive you can download today. Usage is visible in the console; a full audit export is not self-service.
The Operating Calendar — a seat, no code. It is free for two jurisdictions with no account at all, so try it before deciding. Open it.
The Calendar API. Scope is by territory rather than by call volume, so the cost is a function of how many places you cover, not how busy you are. Build a request without writing code.
A Dossier — a prepared PDF for one country, with the sources and the assurance behind every row, carrying an edition on the cover. 241 countries available. Browse them.
Usually not. They are the same corpus prepared three ways: the Calendar API for systems, the Calendar for people planning, the Dossier for a document that has to be defensible six months later. Buy the shape that matches who reads it.