A prayer times feature looks like a small piece of work: fetch five times for a location, render them, highlight the next one. Developers who have shipped one know it is not, and the reason is unusual. The hard part is not the code — it is that there is no single correct answer to what the times are.
Different organisations calculate them differently, and the differences are large enough that users notice. Building this well means understanding where the disagreement comes from before you pick an API.
Quick comparison
| API | Best for | Auth | Coverage | Data basis |
|---|---|---|---|---|
| AlAdhan | Global apps, method flexibility | None | Worldwide | Calculated |
| MuslimSalat | Simple city lookups | None | Worldwide | Calculated |
| İmsakiyem | Turkey, province/district flow | None | Turkey | Turkey-oriented |
| Diyanet AwqatSalah | Matching Turkey's official timetable | Application required | Turkey and beyond | Official publication |
The thing to understand first: calculation methods
Sunrise, noon and sunset are astronomical facts. Fajr and Isha are not — they are defined by how far the sun sits below the horizon at dawn and dusk, and different authorities have settled on different angles.
The Muslim World League, ISNA, Umm al-Qura, the Egyptian General Authority and Turkey's Diyanet each publish their own parameters. Choosing between them changes Fajr and Isha by minutes, sometimes more than ten. Maghrib and Dhuhr also shift slightly depending on whether small time adjustments are applied.
Two practical consequences follow, and they shape the whole feature.
First, if your app shows a different time than the mosque down the road, users will report it as a bug. It is not a bug — it is a method mismatch. Handle it by exposing the method as a user setting with a sensible regional default, not by hard-coding one and hoping.
Second, when you compare APIs during evaluation, compare them with the same method configured. Two APIs returning different times tell you nothing until you have controlled for this.
AlAdhan — the flexible global default
AlAdhan is the most widely used option for applications that are not tied to one country, and it needs no API key.
Its strength is configurability. Every calculation method mentioned above is available as a parameter, along with the school for Asr calculation, manual per-prayer adjustments and high-latitude rules. If your app has a settings screen where users pick their preference, AlAdhan can serve almost any combination they choose.
Coverage is global. You can query by city and country or by coordinates, which matters for apps that use device location rather than a city picker.
It also handles calendars well. Monthly and yearly endpoints return a full timetable in one request, and Hijri dates come alongside Gregorian ones. For Ramadan features — imsak and iftar timetables for the whole month — this is the endpoint you want, not thirty daily calls.
The trade-off is that everything is calculated rather than sourced from an official published timetable. For most global applications this is exactly right. For users who expect their national authority's exact published times, it may differ by a few minutes.
MuslimSalat — simple and quick
MuslimSalat covers similar ground with a simpler surface. City-based lookups, daily and monthly timetables, no key required.
Choose it when your needs are basic and you want the smallest possible integration. If you need fine-grained method control, high-latitude rules or coordinate-based queries, AlAdhan gives you more room.
As with any free community-operated service, verify current availability and limits before depending on it in production.
İmsakiyem — built around Turkey's structure
İmsakiyem is oriented specifically toward Turkey and models the country's administrative hierarchy directly: province, then district.
This matters more than it sounds for a Turkish audience. Users there do not think in coordinates or in "nearest major city" — they think in terms of their district. An interface that asks for a province and then a district matches how people expect to be asked, and İmsakiyem's structure supports that flow without you building the mapping yourself.
It also covers Ramadan calendars, which is the seasonal peak for this category. If your app serves users in Turkey and you want the local selection flow without an application process, this is the practical choice.
Diyanet AwqatSalah — the official Turkish timetable
Diyanet AwqatSalah is the API of Turkey's Presidency of Religious Affairs, and it is the only source here that publishes an official national timetable rather than calculating times.
Use it when exact agreement with Turkey's published calendar is a requirement. Turkish users frequently cross-check against the official calendar, and a few minutes of difference will be noticed and reported.
The cost is access. Unlike the others, it requires an application, credentials and an authenticated token flow, which also means you cannot call it directly from a browser or mobile client — you need a server-side layer. If you are integrating it, we cover the token lifecycle, the province and district hierarchy and the caching strategy step by step in the Diyanet AwqatSalah integration guide.
The high-latitude problem
This is the edge case that breaks prayer times apps, and it is worth handling before launch rather than after a user in Norway files a report.
Above roughly 48 degrees of latitude, there are periods in summer when the sun never dips far enough below the horizon for astronomical dawn or dusk to occur. Fajr and Isha are, strictly speaking, undefined. Closer to the poles the effect lasts for months.
Several conventions exist for resolving this — dividing the night into portions, using the nearest latitude where the times are defined, or applying a fixed interval after sunset and before sunrise. APIs expose these as parameters.
Three rules keep this from becoming a defect. Choose a rule deliberately rather than accepting whatever the default is. Disclose in the interface which rule is being applied when it is in effect, because the times are a convention rather than a calculation. And never let the app return nothing — a blank screen where prayer times should be is the worst possible outcome, and it is what happens when this case is unhandled.
Timezones and the day boundary
Two time-related bugs account for most of the incorrect times users report.
The first is timezone handling. The API returns times for a location, but your server may run in UTC and your user may be travelling. Resolve times against the timezone of the queried location, not the server's timezone and not the device's timezone, unless those are the same thing. Attach the offset explicitly during parsing rather than letting the runtime infer it — development and production machines infer differently, and the bug appears only after deploy.
The second is the day boundary. After Isha, the next prayer is the following day's Fajr. Code that only looks at today's list finds nothing after Isha and shows an empty "next prayer" panel for several hours every night. Always compute the next prayer across a two-day window.
Ramadan adds a related case: imsak is before Fajr, and iftar coincides with Maghrib. If you build a countdown, be explicit about which event you are counting to.
Caching and offline behaviour
Prayer times for a fixed location are deterministic and do not change retroactively, which makes them an ideal caching target — and caching here is not just an optimisation.
Fetch monthly rather than daily. One request returns the whole month, so a user opening the app on day fourteen needs no network call at all. Store the timetable keyed by location, month and calculation method — the method must be part of the key, otherwise changing the setting serves stale times from the old configuration.
This also gives you offline support almost for free, which genuinely matters for this category. Someone checking prayer times in a basement, on a plane or on a weak connection should still see them. An app that shows a loading spinner instead of times it already fetched last week has failed at its one job.
Always store the source and fetch date alongside the times, and show them in the interface. "Source: Diyanet, updated 1 August" builds trust and makes support questions answerable.
Choosing
If you are building for a global audience and want method flexibility, start with AlAdhan. It covers the widest range of configurations and needs no key.
If your integration should be as small as possible and your needs are basic, MuslimSalat is simpler.
If your users are in Turkey and you want the province and district flow without an application process, İmsakiyem fits the local structure.
If matching Turkey's official published timetable exactly is a requirement, Diyanet AwqatSalah is the only source that does that, and the extra setup is the price.
Access details and limits in this article reflect official documentation at the time of publication. Verify current terms before relying on any of these in production.
Related API Deposu entries
Sources
Frequently Asked Questions
›Which prayer times API works without an API key?
AlAdhan and MuslimSalat can be called without registration, which makes them the fastest way to prototype. Diyanet AwqatSalah requires an application and authenticated access.
›Why do two APIs give different prayer times for the same city?
Almost always because they use different calculation methods. Organisations disagree on the sun angles used for Fajr and Isha, and each choice shifts those times by minutes. A difference is not a bug unless the method is the same and the results still differ.
›Which calculation method should I use?
There is no universally correct answer — it depends on which authority your users follow. The safest design is to expose the method as a user setting with a sensible regional default, rather than hard-coding one and hoping it matches expectations.
›How do I handle prayer times at high latitudes?
Above roughly 48 degrees latitude, twilight can persist all night in summer, so Fajr and Isha are not astronomically defined. APIs offer adjustment rules for this. Pick one deliberately, disclose it, and never let your app silently return nothing.
›Do I need official data from a religious authority?
Only if your users expect times to match a published national calendar exactly. Calculation-based APIs may differ from an official timetable by a few minutes, and users who compare will notice. For general global apps, calculated times are normally fine.