Athar API — free prayer times, Qibla, Hijri calendar and moon for developers

Overview

One free REST API for prayer times (a day, a range, a batch, the next prayer, a calendar feed), Qibla, Hijri calendar conversion, Islamic observances, the moon and city lookup — the same calculation core that powers this site and the mobile app. No account, no email, no tracking. Every endpoint below can be tried right on this page.

One core, everywhere

Server and clients share athan-core. A time computed here and a time computed offline on a phone are the same time — never a second implementation that quietly drifts.

Nothing to sign

Every calculation endpoint answers anonymously. A key only raises your ceiling; it identifies no person, because no account exists to identify.

Readable, not clever

Plain JSON, wall-clock strings, no envelopes or cursors. If you can read a URL you can read this API.

Quickstart

Every endpoint except the batch is a plain GET request. No auth header required — an optional API key only raises your rate limit.

curl "https://api.openathar.org/v1/prayer-times?lat=52.52&lon=13.405&date=2026-09-14&utcOffset=2"

That is the whole onboarding. No key, no header, no handshake — paste the URL in a browser and you have your first response.

Conventions

Rules that hold for every endpoint, so they are not repeated in each one below.

Base URL: https://api.openathar.org — all paths are prefixed with /v1.
Format: JSON only, UTF-8. No XML, no envelope — the resource is the response body.
Dates: ISO 8601 (YYYY-MM-DD) in, ISO 8601 out. Timestamps are UTC with a trailing Z.
Times: Local wall-clock HH:mm strings, already shifted by the utcOffset you pass. No timezone database needed client-side.
Missing values: A time that does not exist — sunrise during polar day, Isha without a night — is null. Never a placeholder like 00:00.
Coordinates: Decimal degrees, never degrees/minutes/seconds. Latitude −90…90, longitude −180…180.
Auth: Optional. Send X-API-Key to lift the rate limit; omit it and the endpoint still answers.
Caching: Calculation results are deterministic and sent with Cache-Control: public, max-age=31536000, immutable — cache them forever. The exceptions are answers that mean “now”: /v1/hijri, /v1/events and /v1/prayer-times.ics without a date are cached for five minutes to an hour, /v1/prayer-times/next and /v1/moon without at not at all. Lookups (/v1/methods, /v1/places) are cached for a day.
CORS: Browser calls are allowed from openathar.org and, for local development, http://localhost:3000; any other origin gets 403. Call the API from your server, a mobile app or a script — CORS does not apply there — or proxy it through your own backend.
Errors: Always the same shape: {"error": "…"} — see Errors below.
Versioning: The path carries the major version. Breaking changes land on /v2, never silently on /v1.

Endpoints

Prayer times (one day, a range, a batch, the next prayer, a calendar feed), the calculation methods, Qibla, Hijri calendar and observances, the moon, and city lookup. Answers are deterministic — the same input always produces the same output — except the ones that mean “now” (/v1/prayer-times/next and /v1/moon without an at parameter), which are never cached.

GET/v1/prayer-timeskey optional

Prayer times

Computes the prayer times for one location, one date and one calculation method. Times come back as local wall-clock strings (HH:mm) already shifted by the utcOffset you pass — no timezone database needed on your side. The maths is the same athan-core code that runs inside the Athar apps, so a client and the server always agree. At high latitudes in summer, when the sun never sinks far enough for Fajr or Isha, both are placed by the middle-of-the-night rule. Where an event does not happen at all — polar day or polar night — its field is null, never a made-up time.

Parameters

latnumberrequired
Latitude in decimal degrees, −90 to 90.
lonnumberrequired
Longitude in decimal degrees, −180 to 180.
datedaterequired
Gregorian date, ISO 8601 (YYYY-MM-DD).
methodenumdefault MWL
Twilight angle set used for Fajr and Isha.
MWL · ISNA · EGYPT · MAKKAH · KARACHI · TEHRAN · JAFARI · FRANCE · RUSSIA · MALAYSIA · SINGAPORE
utcOffsetnumberdefault 0
Hours offset applied to render local times, −12 to 14. Fractional offsets (5.5) are allowed.

Response · 200

{
  "date": "2026-09-14",
  "method": "MWL",
  "latitude": 52.52,
  "longitude": 13.405,
  "utcOffsetHours": 2.0,
  "fajr": "04:38",
  "sunrise": "06:39",
  "dhuhr": "13:02",
  "asr": "16:30",
  "sunset": "19:24",
  "maghrib": "19:25",
  "isha": "21:17",
  "midnight": "01:02",
  "duhaStart": "06:54",
  "duhaEnd": "12:52",
  "duhaBest": "09:51"
}

date: string The requested date, echoed back.
method: string Calculation method actually used.
latitude / longitude: number Coordinates echoed back.
utcOffsetHours: number Offset applied to the wall-clock strings.
dhuhr: string HH:mm local time. Always present.
fajr / asr / maghrib / isha: string | null HH:mm local time; null where the prayer does not occur (polar day or night).
sunrise / sunset: string | null Solar events bounding the day; null during polar day or night.
midnight: string | null Islamic midnight. Standard methods: solar midnight, always present. TEHRAN / JAFARI: midpoint of sunset and Fajr, null where either is missing.
duhaStart / duhaBest / duhaEnd: string | null Forenoon prayer window and its recommended moment; all null when there is no sunrise.

Example request

curl "https://api.openathar.org/v1/prayer-times?lat=52.52&lon=13.405&date=2026-09-14&utcOffset=2"

GET/v1/prayer-times/rangekey optional

Date ranges

The same calculation as the daily endpoint for each day of an inclusive date range, in one call — a printable month costs one request instead of thirty. Every entry in days is exactly what /v1/prayer-times returns for that date. At most 62 days per call; a longer range, or a to before from, returns 400. Like the daily endpoint it is deterministic and cached forever.

Parameters

latnumberrequired
Latitude in decimal degrees, −90 to 90.
lonnumberrequired
Longitude in decimal degrees, −180 to 180.
fromdaterequired
First day, ISO 8601 (YYYY-MM-DD).
todaterequired
Last day, inclusive. At most 62 days after from.
methodenumdefault MWL
Calculation method. See /v1/methods for what each one means.
MWL · ISNA · EGYPT · MAKKAH · KARACHI · TEHRAN · JAFARI · FRANCE · RUSSIA · MALAYSIA · SINGAPORE
utcOffsetnumberdefault 0
Hours offset applied to render local times, −12 to 14.

Response · 200

{
  "from": "2026-09-14",
  "to": "2026-09-15",
  "method": "MWL",
  "latitude": 52.52,
  "longitude": 13.405,
  "utcOffsetHours": 2.0,
  "days": [
    { "date": "2026-09-14", "method": "MWL", "fajr": "04:38", "sunrise": "06:39", "dhuhr": "13:02", "asr": "16:30", "sunset": "19:24", "maghrib": "19:25", "isha": "21:17", "midnight": "01:02", "duhaStart": "06:54", "duhaEnd": "12:52", "duhaBest": "09:51", "…": "…" },
    { "date": "2026-09-15", "…": "…" }
  ]
}

from / to: string The requested range, echoed back.
method: string Calculation method actually used.
latitude / longitude / utcOffsetHours: number Inputs echoed back.
days: object[] One entry per day, in date order, in the shape of the /v1/prayer-times response.

Example request

curl "https://api.openathar.org/v1/prayer-times/range?lat=52.52&lon=13.405&from=2026-09-14&to=2026-09-15&utcOffset=2"

GET/v1/prayer-times/nextkey optional

Current & next prayer

Answers the question every prayer app asks: which prayer has most recently started, which one comes next, and how many seconds are left. It rolls over midnight correctly — before Fajr the current prayer is yesterday’s Isha, after Isha the next one is tomorrow’s Fajr — and skips prayers that do not occur at the location (polar day or night). Without at the answer is for the current moment and is not cached; with an explicit at it is deterministic and cached forever.

Parameters

latnumberrequired
Latitude in decimal degrees, −90 to 90.
lonnumberrequired
Longitude in decimal degrees, −180 to 180.
methodenumdefault MWL
Calculation method. See /v1/methods.
MWL · ISNA · EGYPT · MAKKAH · KARACHI · TEHRAN · JAFARI · FRANCE · RUSSIA · MALAYSIA · SINGAPORE
utcOffsetnumberdefault 0
Hours offset of the location, −12 to 14. Decides the local date and time.
atstringdefault now
The moment to answer for, as an ISO 8601 instant. Useful for testing; defaults to now.

Response · 200

{
  "method": "MWL",
  "latitude": 52.52,
  "longitude": 13.405,
  "utcOffsetHours": 2.0,
  "localTime": "2026-09-14T17:30:00",
  "current": { "name": "asr", "date": "2026-09-14", "time": "16:30" },
  "next": { "name": "maghrib", "date": "2026-09-14", "time": "19:25" },
  "secondsUntilNext": 6900
}

localTime: string The moment the answer is for, as local date-time (utcOffset applied).
current: object The latest prayer that has started: name (fajr, dhuhr, asr, maghrib, isha), date and HH:mm time.
next: object The next prayer to start, same shape. Can be on the following date.
secondsUntilNext: number Seconds from localTime until next starts.
method / latitude / longitude / utcOffsetHours: string | number Inputs echoed back.

Example request

curl "https://api.openathar.org/v1/prayer-times/next?lat=52.52&lon=13.405&utcOffset=2&at=2026-09-14T15%3A30%3A00Z"

GET/v1/methodskey optional

Calculation methods

The catalogue behind the method parameter: each accepted id with its authority, the Fajr angle, the Isha and Maghrib rules and the midnight rule. Build a settings picker from this instead of hardcoding a list that goes stale. Fajr is always an angle below the horizon; Isha and Maghrib are either an angle or a fixed number of minutes. All methods use the standard Asr shadow rule and place Fajr and Isha by the middle-of-the-night rule where the sun does not sink far enough. Cached for a day.

Parameters

None.

Response · 200

{
  "methods": [
    {
      "id": "MWL",
      "name": "Muslim World League",
      "fajrAngle": 18.0,
      "isha": { "type": "angle", "value": 17.0 },
      "maghrib": { "type": "minutes", "value": 1.0 },
      "midnight": "STANDARD"
    },
    { "id": "MAKKAH", "name": "Umm al-Qura University, Makkah", "fajrAngle": 18.5, "isha": { "type": "minutes", "value": 90.0 }, "…": "…" }
  ],
  "asr": "STANDARD",
  "highLatitude": "NIGHT_MIDDLE"
}

methods[].id: string Value for the method parameter.
methods[].name: string The authority or convention behind it.
methods[].fajrAngle: number Sun depression angle for Fajr, in degrees.
methods[].isha / maghrib: object { type: "angle" | "minutes", value } — degrees below the horizon, or minutes (after Maghrib for Isha, after sunset for Maghrib).
methods[].midnight: string STANDARD (solar midnight) or JAFARI (midpoint of sunset and Fajr).
asr / highLatitude: string Rules shared by every method: STANDARD and NIGHT_MIDDLE.

Example request

curl "https://api.openathar.org/v1/methods"

POST/v1/prayer-times/batchkey optional

Batch prayer times

For mosque directories, dashboards and multi-city widgets: send many locations in one body and get the prayer times back in the same order, each with the label you sent. At most 50 locations per call. The whole request is rejected if one location is invalid, and the message names its index (locations[3]: latitude out of range). One batch counts as one request against the rate limit. POST responses are not cached.

Parameters

None. Everything goes in the JSON body below.

Request body

{
  "date": "2026-09-14",
  "method": "MWL",
  "locations": [
    { "label": "berlin", "lat": 52.52, "lon": 13.405, "utcOffset": 2 },
    { "label": "makkah", "lat": 21.4225, "lon": 39.8262, "utcOffset": 3 }
  ]
}

Response · 200

{
  "date": "2026-09-14",
  "method": "MWL",
  "results": [
    { "label": "berlin", "times": { "date": "2026-09-14", "fajr": "04:38", "dhuhr": "13:02", "…": "…" } },
    { "label": "makkah", "times": { "date": "2026-09-14", "…": "…" } }
  ]
}

date / method: string Echoed back.
results[].label: string | null The label you sent for that location.
results[].times: object Same shape as the /v1/prayer-times response.

Example request

curl -X POST "https://api.openathar.org/v1/prayer-times/batch" \
  -H "Content-Type: application/json" \
  -d '{ "date": "2026-09-14", "method": "MWL", "locations": [ { "label": "berlin", "lat": 52.52, "lon": 13.405, "utcOffset": 2 }, { "label": "makkah", "lat": 21.4225, "lon": 39.8262, "utcOffset": 3 } ] }'

GET/v1/prayer-times.icskey optional

Calendar feed (iCalendar)

An iCalendar feed (text/calendar) that Apple Calendar, Google Calendar and Outlook can subscribe to by URL, so prayer times show up in a calendar people already use. One short event per prayer, optionally sunrise, for days days from from (default: today, 30 days, at most 62). Event times are written in UTC and are therefore right on every device. Calendar apps refresh the feed on their own; because the window starts today, it keeps rolling forward. With an explicit from the feed is cached forever, otherwise for an hour.

Parameters

latnumberrequired
Latitude in decimal degrees.
lonnumberrequired
Longitude in decimal degrees.
fromdatedefault today
First day, ISO 8601.
daysnumberdefault 30
Number of days, 1 to 62.
methodenumdefault MWL
Calculation method. See /v1/methods.
MWL · ISNA · EGYPT · MAKKAH · KARACHI · TEHRAN · JAFARI · FRANCE · RUSSIA · MALAYSIA · SINGAPORE
utcOffsetnumberdefault 0
Hours offset of the location, −12 to 14.
langenumdefault en
Language of the event names.
en · de · ar
sunrisestringdefault false
true adds a sunrise event.

Response · 200

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Athar//Prayer times//EN
X-WR-CALNAME:Prayer times
REFRESH-INTERVAL;VALUE=DURATION:PT12H
BEGIN:VEVENT
UID:fajr-2026-09-14-52.52,[email protected]
DTSTART:20260914T023800Z
DTEND:20260914T024800Z
SUMMARY:Fajr
TRANSP:TRANSPARENT
END:VEVENT
…
END:VCALENDAR

(body): text/calendar A VCALENDAR with one VEVENT per prayer: SUMMARY is the prayer name, DTSTART in UTC, ten minutes long, marked as free time.

Example request

curl "https://api.openathar.org/v1/prayer-times.ics?lat=52.52&lon=13.405&from=2026-09-14&utcOffset=2"

GET/v1/moonkey optional

Moon phase

The moon at an instant (default: now): phase name, illuminated fraction, age in days, and the next new and full moon as UTC instants. It is calculated from the true times of new and full moon (Meeus), accurate to a couple of minutes — the same astronomy that drives the visuals on openathar.org. It is astronomy, not a moon sighting: a Hijri month begins with the observed crescent, not with the conjunction. With at the answer is cached forever, without it not at all.

Parameters

atstringdefault now
ISO 8601 instant.

Response · 200

{
  "at": "2026-09-14T15:30:00Z",
  "phase": "waxing-crescent",
  "illumination": 0.1326,
  "ageDays": 3.5,
  "phaseAngleDegrees": 42.7,
  "previousNewMoon": "2026-09-11T03:26:58Z",
  "nextNewMoon": "2026-10-10T15:49:58Z",
  "nextFullMoon": "2026-09-26T16:48:56Z"
}

phase: string new, waxing-crescent, first-quarter, waxing-gibbous, full, waning-gibbous, last-quarter or waning-crescent.
illumination: number Illuminated fraction of the disc, 0 to 1.
ageDays: number Days since the last new moon.
phaseAngleDegrees: number 0 = new, 180 = full, along the lunation.
previousNewMoon / nextNewMoon / nextFullMoon: string UTC instants.

Example request

curl "https://api.openathar.org/v1/moon?at=2026-09-14T15%3A30%3A00Z"

GET/v1/eventskey optional

Islamic observances

The next observances from a date, in order, each with its Hijri date, Gregorian date and the days until it: Islamic New Year, Ashura, Mawlid, start of Ramadan, Laylat al-Qadr, Eid al-Fitr and Eid al-Adha. These are calendar facts from the Umm al-Qura calendar; a local moon sighting may differ by a day, and two entries are worded neutrally on purpose — Mawlid is a date, not a call to observe it, and the night of Laylat al-Qadr is stated as unknown. With from the answer is cached forever, otherwise for an hour.

Parameters

fromdatedefault today
Count days from here, ISO 8601.
countnumberdefault 5
How many observances, 1 to 20.
localeenumdefault en
Language of names and notes.
en · ar · de

Response · 200

{
  "from": "2026-09-14",
  "locale": "en",
  "events": [
    {
      "key": "ramadan-start",
      "name": "Start of Ramadan",
      "note": "Subject to moon sighting; the calculated date may shift by a day.",
      "hijriDay": 1, "hijriMonth": 9, "hijriYear": 1448,
      "gregorianDate": "2027-02-08",
      "daysUntil": 147
    }
  ]
}

events[].key: string Stable identifier, e.g. ramadan-start.
events[].name / note: string Localized name and a one-line note.
events[].hijriDay / hijriMonth / hijriYear: number The Hijri date.
events[].gregorianDate: string The Gregorian date.
events[].daysUntil: number Days from from; 0 on the day itself.

Example request

curl "https://api.openathar.org/v1/events?from=2026-09-14&count=3"

GET/v1/calendar/hijrikey optional

Hijri month grid

A whole Umm al-Qura month with the Gregorian date and weekday of every day — enough to draw a Hijri calendar without shipping any conversion logic. Years 1300 to 1600 AH are supported (the span of the table); anything else returns 400. Cached forever.

Parameters

yearnumberrequired
Hijri year, 1300 to 1600.
monthnumberrequired
Hijri month, 1 to 12.
localeenumdefault en
Language of the month name.
en · ar · de

Response · 200

{
  "year": 1448,
  "month": 4,
  "monthName": "Rabi' al-thani",
  "length": 30,
  "days": [
    { "day": 1, "gregorianDate": "2026-09-12", "weekday": "SATURDAY" },
    { "day": 2, "gregorianDate": "2026-09-13", "weekday": "SUNDAY" },
    { "day": 3, "gregorianDate": "2026-09-14", "weekday": "MONDAY" },
    "…"
  ]
}

year / month / monthName: number | string The month, with its localized name.
length: number 29 or 30.
days[]: object[] day, gregorianDate and weekday (English, upper case) for every day.

Example request

curl "https://api.openathar.org/v1/calendar/hijri?year=1448&month=4"

GET/v1/calendar/gregoriankey optional

Hijri to Gregorian

Converts a Hijri (Umm al-Qura) date to its Gregorian date — the counterpart of /v1/hijri. The response has the same shape. A day that does not exist in that month (the 30th of a 29-day month) returns 400. Cached forever.

Parameters

yearnumberrequired
Hijri year, 1300 to 1600.
monthnumberrequired
1 to 12.
daynumberrequired
1 to 30.
localeenumdefault en
Language of monthName.
en · ar · de

Response · 200

{
  "gregorianDate": "2026-09-14",
  "day": 3,
  "month": 4,
  "year": 1448,
  "monthName": "Rabi' al-thani"
}

gregorianDate: string The Gregorian date.
day / month / year / monthName: number | string The Hijri date that was converted.

Example request

curl "https://api.openathar.org/v1/calendar/gregorian?year=1448&month=4&day=3"

GET/v1/placeskey optional

City lookup

Most integrations start from a city name, not from coordinates. This resolves a name — Latin or Arabic script, accents ignored — to the latitude, longitude, IANA time zone and the UTC offset on a date, daylight saving included, which are exactly the inputs the prayer-time endpoints need. It covers cities above 15,000 people and runs on a bundled dataset, so no query is ever sent to a third-party geocoder. Best match first: exact name, then prefix, then contained; larger cities first within a tier. Data: GeoNames, CC BY 4.0 — the response names it as source. Cached for a day.

Parameters

qstringrequired
City name, at least 2 characters.
limitnumberdefault 10
Maximum results, 1 to 25.
datedatedefault today
Date for the UTC offset (daylight saving).

Response · 200

{
  "query": "berlin",
  "source": "GeoNames (CC BY 4.0), https://www.geonames.org/",
  "places": [
    {
      "name": "Berlin",
      "country": "DE",
      "latitude": 52.52437,
      "longitude": 13.41053,
      "timezone": "Europe/Berlin",
      "utcOffsetHours": 2.0,
      "population": 3426354
    }
  ]
}

source: string Attribution required by the data licence.
places[].name / country: string City and ISO country code.
places[].latitude / longitude: number Coordinates.
places[].timezone: string IANA time zone.
places[].utcOffsetHours: number Offset on the requested date — pass it as utcOffset.
places[].population: number Inhabitants, used for ranking.

Example request

curl "https://api.openathar.org/v1/places?q=berlin&limit=5&date=2026-09-14"

GET/v1/qiblakey optional

Qibla

Returns the direction of prayer for a location as a bearing in degrees from true north. It is a great-circle bearing, not a flat-map heading — compass apps should correct for magnetic declination themselves before drawing an arrow.

Parameters

latnumberrequired
Latitude in decimal degrees, −90 to 90.
lonnumberrequired
Longitude in decimal degrees, −180 to 180.

Response · 200

{
  "latitude": 52.52,
  "longitude": 13.405,
  "bearingDegrees": 136.6848865372571
}

latitude / longitude: number Coordinates echoed back.
bearingDegrees: number 0 = true north, 90 = east. Range 0–360, full precision — round for display.

Example request

curl "https://api.openathar.org/v1/qibla?lat=52.52&lon=13.405"

GET/v1/hijrikey optional

Hijri date

Converts a Gregorian date into the Umm al-Qura calendar — the precomputed astronomical table Saudi Arabia uses as its civil calendar. A local moon sighting may legitimately differ by a day, so treat the result as the civil reference rather than a religious ruling. Supported range is the span of that table: 1882-11-12 to 2174-11-25 (1300–1600 AH); dates outside it return 400. With an explicit date the response is cached forever; without one it means “today” and is cached for five minutes only.

Parameters

datedatedefault today
Gregorian date to convert, 1882-11-12 to 2174-11-25. Defaults to today (UTC).
localeenumdefault en
Language of monthName. de uses the same transliteration as en.
en · ar · de

Response · 200

{
  "gregorianDate": "2026-09-14",
  "day": 3,
  "month": 4,
  "year": 1448,
  "monthName": "Rabi' al-thani"
}

gregorianDate: string The date that was converted.
day / month / year: number Hijri components. Month is 1–12.
monthName: string Localized month name, per locale.

Example request

curl "https://api.openathar.org/v1/hijri?date=2026-09-14"

API key endpoints

Keys are issued on demand. They raise your rate limit and nothing else — no plan, no quota to buy, no identity attached.

POST/v1/api-keyspublic

Issue an API key

Issues an API key instantly — no sign-up, no email, no billing. The key is shown exactly once in the response; lose it and you simply issue another one. The optional label (max 64 characters, default “unlabeled”) is only there to tell your keys apart. A mistyped or unknown key in X-API-Key is never rejected — the request simply counts as anonymous.

Parameters

None. An optional JSON body lets you label the key.

Request body

{
  "label": "my-prayer-widget"
}

Response · 200

{
  "apiKey": "ath_x7Kp2mQ9vLr4TnW8bYc3HdF6jZs1Ne5A",
  "label": "my-prayer-widget",
  "createdAt": "2026-09-14T09:12:03Z"
}

apiKey: string Send as the X-API-Key header. Shown once.
label: string Your label, max 64 characters; “unlabeled” if omitted.
createdAt: string ISO 8601 timestamp.

Example request

curl -X POST "https://api.openathar.org/v1/api-keys" \
  -H "Content-Type: application/json" \
  -d '{ "label": "my-prayer-widget" }'

GET/v1/api-keys/{apiKey}/usagekey in path

Key usage

A usage snapshot for a single key. Counting is per key, not per user — Athar stores no identity to attach it to.

Parameters

apiKeystringrequired
Path segment, not a query parameter or header.

Response · 200

{
  "label": "my-prayer-widget",
  "createdAt": "2026-09-14T09:12:03Z",
  "requestCount": 1423
}

label: string Label given at creation.
createdAt: string When the key was issued.
requestCount: number Total requests made with this key.

Example request

curl "https://api.openathar.org/v1/api-keys/ath_YOUR_KEY/usage"

Rate limits

A fixed one-minute window, counted per client IP — or per API key when you send one.

Anonymous

60 requests / minute

counted by IP address

With X-API-Key

600 requests / minute

counted by key

Exceeding the window returns 429 with a Retry-After header in seconds. The limiter fails open: if its store is unreachable your request is served rather than rejected. Responses served from a browser or CDN cache never reach the API, so they count neither against the limit nor towards a key's usage — caching is the cheapest way to stay under the ceiling.

Get a free API key

Instant, no email, no account. A key raises your rate limit from 60 to 600 requests per minute — it is not an identity system.

Label (optional, for your own reference)

Check usage

Look up the request count for a key you already hold.

Try it live

Edit the parameters and run a real request against the live API — right from this page.

latlondatemethodutcOffsetAPI key (optional)

curl "https://api.openathar.org/v1/prayer-times?lat=52.52&lon=13.405&date=2026-10-22&method=MWL&utcOffset=0"

Response

—

Errors

Every error on every endpoint has the same shape: one field with a human-readable message. Nothing to special-case per endpoint.

{
  "error": "missing required parameter: lat"
}

Status	Meaning	What to do
400	Bad request	A required parameter is missing or does not parse, a value is out of range (latitude, longitude, utcOffset, a Hijri date outside 1882–2174), the method is unknown, the JSON body is malformed, or a key label exceeds 64 characters. The message says which.
404	Not found	Unknown path — or, on the usage endpoint, a key that does not exist ("unknown API key").
405	Method not allowed	Wrong HTTP method for the path. The Allow header lists the right one.
415	Unsupported media type	POST bodies must be sent as Content-Type: application/json. A bare curl -d sends form data and lands here.
429	Rate limited	You crossed the window limit. Wait for the seconds given in the Retry-After header, or send an API key for the higher ceiling.
500	Server error	Something broke on the Athar side; the message is deliberately generic. Worth an issue on GitHub — include the full request URL.

The one exception is a CORS rejection (403) for browser calls from other origins: it is answered before the API runs, and browsers do not show its body to scripts anyway.

Roadmap

What the API does not do yet, and in which order that is likely to change. Published openly so you can plan around the gaps — or close one yourself with a pull request.

GET/v1/quran/verseexploring
Quran & Adhkar content
The largest expansion, and the one that turns a calculation API into a platform API. Needs a licence-clean text source and careful versioning before it can be promised.

Missing something that is not on this list? Open an issue — the roadmap is shaped by what people actually try to build.

That's it

Deterministic in, deterministic out. Build whatever you want on top — a widget, a bot, a smart-speaker skill. If something's missing, open an issue.

Source on GitHub →Full OpenAPI reference →athan-core →

Build on the samesky we do.

Overview

One core, everywhere

Nothing to sign

Readable, not clever

Quickstart

Conventions

Endpoints

API key endpoints

Rate limits

Get a free API key

Try it live

Errors

Roadmap

That's it

Build on the same
sky we do.