Calendar — entry 013 of 17
Non-Working Days
isdayoff.ru answers one narrow question extremely cheaply: for a date or date range, is it a working day, a weekend, or an official non-working holiday. Responses are bare digit strings (0/1 per day, or 2 for a shortened day) rather than JSON, which keeps payloads tiny for the batch/range endpoint. It documents Russia, Belarus, Ukraine, Kazakhstan, and the US as supported country codes, but live probes this run found only Russia (the default), Belarus, and Kazakhstan return genuinely varying data — the Ukraine and US codes are accepted (HTTP 200) but answered every single day of several different months with a flat, undifferentiated "0". It's free, keyless, and has no published rate limit, built for production-calendar bookkeeping rather than general holiday metadata.
isdayoff.ru answers one narrow question extremely cheaply: for a given date, is it a working day (`0`), a non-working day/weekend/holiday (`1`), or a shortened day (`2`) -- returned as a bare digit string, not JSON. A live GET this run against today's date (2026-07-29, a Wednesday) returned a single-byte `0`, and a whole-month range for January 2026 returned a 31-character string, one digit per day, with `content-type: text/plain`.
GreatAPIs Score
Embed this badge
<a href="https://greatapis.com/api/non-working-days-calendar/"><img src="https://greatapis.com/badge/non-working-days-calendar.svg" alt="Scored 74 on greatapis.com"></a>Auth quickstart
- No API key, signup, or credit card required. A live GET this run confirmed every route answers keyless with `access-control-allow-origin: *` and no rate-limit headers of any kind.
Your key is stored only in this browser (localStorage) and sent directly to the API — never to greatapis.
Check whether today is a working day (Russia calendar)
GEThttps://isdayoff.ru/20260729
0
Try it
Developer reference
https://isdayoff.ru- GET/{date}
- GET/api/getdata?year={year}&month={month}
- GET/api/getdata?year={year}
Gotchas & limits
- An invalid date returns its error as an indistinguishable digit string, not a JSON error object -- a live GET this run against `/20261332` (month 13) returned HTTP 400 whose entire body is the bare string `100`, the same shape as a real multi-day answer; only the HTTP status line separates a genuine result from a rejected request.
- The `cc` (country code) query parameter only works on the `/api/getdata` range route, not on the bare `/{date}` route -- a live GET this run against `/20260101?cc=us` returned HTTP 404 whose body is a different bare digit string, `101`, again shaped identically to a real answer.
- Two of the country codes this API documents as supported return no real day-type data at all -- live GETs this run against `/api/getdata?year=2026&month={1,7,12}&cc=us` and `/api/getdata?year=2026&month=1&cc=ua` returned HTTP 200 with an unbroken string of `0`s for every single day across all four months checked (not even weekends marked), while the same query with `cc=by`, `cc=kz`, or `cc=uz` returned genuinely varying data -- code trusting the docs' full country list needs to verify output before relying on `us`/`ua`.
- The range route accepts a bare `year` with no `month` and returns the whole year in one call -- a live GET this run against `/api/getdata?year=2026` returned a single 365-character string (2026 isn't a leap year), one digit per day of the full year, in the same digit-per-day shape as a single-month request.