Send a date and coordinates — get Fajr, sunrise, Dhuhr, Asr, Maghrib, and Isha, computed directly from the sun's position for that exact place and day, not read from a fixed city table. Because the answer for a given place and day never changes, an entire city opening their apps at the same prayer moment collapses to a single computation served from cache — the synchronized surge that forces other services to over-provision barely moves ours. And every response ships the raw solar angles it used, so nothing is a black box.
You didn't set out to write timezone logic, high-latitude rescue rules, and moon-phase maths. But these are the bugs that eat the roadmap and the complaints that read as "this app is broken." Here's the ache — and what NOUS takes off your plate.
Your whole city's apps refresh and fire notifications at the same prayer moment. If your source recomputes per request, you provision and pay for the peak, not the average — and a free tier throttles exactly when it matters most.
NOUS: a fresh compute costs ~150 µs on one of eight cores, so even an all-unique-coordinate surge is cheap to serve — and repeated city-level lookups collapse to cache hits on top. The peak barely moves the bill.
Coordinate-only APIs leave timezone and daylight-saving to you. One wrong offset and every prayer time is an hour off — the classic support ticket that only shows up on the day the clocks change.
NOUS: send a place and a date; civil times come back already in that place's own clock, historical and DST offset applied, with tz reported for audit.
Above roughly 48°, Fajr and Isha can stop occurring near the solstices — users in northern Europe and Canada see missing or absurd times, a hard visible failure.
NOUS: exact per-request solar geometry plus the recognised high-latitude rescue rules — and the rule choice stays yours, because it's jurisdictional, not a fact we should fake.
Start-of-month dates split by country every year because sighting rules differ. Hardcode one date and you anger the other half of your users — right at your highest-traffic moment.
NOUS: live crescent data — phase, elongation, illumination — plus sunset rise/set, the raw ingredients to show why a date is disputed instead of asserting one.
method=Egypt really Egypt?"Most services hand you a method name and hide the angles behind it. If those parameters are a quiet reimplementation, the times are wrong for that community — and a devotional app can't afford to lose that trust.
NOUS: every reply returns the exact angles it used — fajr_angle, isha_angle, asr_factor — so you verify the numbers, not a label.
Prayer times, Qibla, Hijri date, and crescent data stitched from three or four separate free services multiplies the number of unfunded, SLA-less things that can fail on you at once.
NOUS: all of it from one deterministic engine on the same bounded-cost substrate — bundling reduces your peak risk instead of multiplying it.
Pick a tab, fill in a date and place, hit run. Live tabs call the actual gateway; anything not yet exposed over HTTP is clearly marked as a sample.
Every figure here is measured on this engine, not a marketing estimate.
| Capability | NOUS Prayer Times API | Typical hosted prayer-time services |
|---|---|---|
| Calculation basis | Direct solar-angle geometry, computed per request | Fixed angle constants, often from a shared table |
| Behavior at peak | Deterministic per place/day — a city-wide surge collapses to one cached answer, so peak barely adds cost | Recompute or database hit per request — the 5-a-day surge is what you provision (and pay) for |
| Location precision | Exact latitude/longitude, no city list | Nearest listed city, or manual angle configuration |
| Raw solar angles | Returned with every response (fajr_angle, isha_angle, asr_factor) | Times only — the underlying angles are hidden |
| Integration | Single GET call, flat JSON response | Hosted API or a client-side library you run yourself |
The prayer-times market is full of free options that all do roughly the same thing. These are the four places NOUS is structurally different — not louder, different.
Every response returns the exact solar angles it used — fajr_angle, isha_angle, asr_factor — and its own compute time. You can verify that method=Egypt is really the Egypt parameters, not a reimplementation. Check the numbers instead of trusting a label — the one thing a devotional product can't afford to get wrong.
Prayer times, Qibla bearing, the Hijri date, and crescent data all come from one deterministic engine. Everywhere else you stitch three or four separate free services together — and quietly inherit the combined peak-failure risk of every one of them.
Send a place and a date; get civil times in that place's own clock, with the correct historical and daylight-saving offset already applied, and tz / utc_offset_s reported back for audit. No timezone database to ship, no once-a-year off-by-an-hour bug — the integration that usually breaks prayer products.
The engine takes a date and a point and returns geometry. No account, no user profile, no location retained. For a devotional category that has been burned by location-data scandals, that's a far smaller privacy surface to defend.
Every prayer-times API is free of charge — but "free" is a rate cap, not a gift. Here is the chain that forces every serious prayer app to pay someone, and why the cheapest someone is a hosted engine whose cost is bounded at the peak.
1 — The peak sets your cost, not the average. Prayer traffic is not smooth. Apps refresh and fire notifications in five hard, city-wide waves a day — a whole timezone reaches the same prayer moment at once. You have to provision for that peak second, not your daily average.
2 — So a monthly quota is the wrong number; the peak second is the right one. That is exactly where the free tiers throttle: a marketplace prayer API allows 1,000 requests/hour — 0.28 req/s; Aladhan is capped near a dozen req/s per IP with no paid tier to raise it. Under the wave the failure lands at the prayer moment — the worst possible time to break.
3 — The "no rate limit" option doesn't throttle — it bills. A paid astronomy API that promises no cap has to serve every request as a fresh compute, so a 100× spike is a 100× invoice. Throttle or an unpayable bill: those are the two failure modes.
4 — A cache doesn't rescue them. Real apps send each user's exact GPS, so a synchronised spike is thousands of distinct cache keys, not one key repeated — the hit rate collapses toward zero. Round the coordinates to force hits and you break accuracy at city borders (the documented reason one team abandoned its API for on-device math). Their per-miss cost stays heavy — hundreds of milliseconds a call.
5 — So "free" is never the real price. You pay it as throttled failures at adhan, as the DevOps bill of self-hosting the open-source stack, or as owning method fidelity, high-latitude rules and DST correctness on-device forever. Every door costs; the only choice is which.
6 — NOUS changes which door is cheapest. A cache miss costs about 150 microseconds on one of eight worker cores, so even an all-unique-coordinate spike is cheap for us to serve — no high hit-rate required. Repeated city-level and monthly-schedule lookups then collapse to memory-speed cache hits on top. Because our marginal cost at peak is bounded, we can commit a per-second ceiling and hold every tier ~20% under the nearest funded comparable. The hosted call becomes the cheapest path that actually holds at peak.
Every capability below is computed and verified in the engine. The prayer, crescent, and solar-Qibla verbs answer live today; the Qibla-bearing, Hijri, and monthly routes exist and are being wired onto the public gateway. Here's the complete list.
Year, month, day, latitude, longitude — plain query parameters, no SDK required.
The sun's position is calculated directly for that exact date and location.
Sun-altitude thresholds mark Fajr and Isha and shadow-length rules mark Asr — the engine computes any of 16 conventions (Muslim World League, ISNA, Egyptian, Karachi, Umm al-Qura, Dubai, Qatar, Gulf, Kuwait, Singapore, France, Turkey, Russia, Tehran, Jafari) plus the Moonsighting Committee method, with Shafiʻi or Hanafi Asr, Sunni or Shia midnight, high-latitude rescue, and custom angles — every knob defaulted sanely.
Ten named times — imsak, Fajr, sunrise, Dhuhr, Asr, Maghrib, Isha, midnight and the night thirds — each as an exact and a civil value, with the Hijri date and Qibla bearing folded in. One flat, predictable response.
Drop-in prayer time computation for consumer apps that need accurate times without shipping their own solar-position code.
The same call gives you the fasting window — sunrise ends Suhoor, Maghrib is Iftar — and the crescent/Hilal endpoint feeds the Ramadan and Eid start dates.
Prayer alerts fire in synchronized waves. A deterministic, cache-friendly response absorbs the surge instead of forcing you to over-provision for five daily peaks.
Generate accurate daily prayer schedules for a specific community's exact coordinates.
Recompute prayer times instantly as a user's location changes, without a lookup table to keep in sync.
Fold prayer times into an existing calendar or notification pipeline with a single call per day.
{
"ok": true,
"fields": {
"date": "2026-07-06",
"lat": 21.4225,
"lon": 39.8262,
"method": "MWL",
"fajr_angle": 18.0,
"isha_angle": 17.0,
"asr_factor": 1,
"fajr": "03:58:19",
"sunrise": "05:23:00",
"dhuhr": "12:04:46",
"asr": "15:22:29",
"maghrib": "18:46:25",
"isha": "20:05:51",
"compute_us": 672
},
"raw": "OK date=2026-07-06 lat=21.4225 lon=39.8262 method=MWL fajr_angle=18.0 isha_angle=17.0 asr_factor=1 fajr=03:58:19 sunrise=05:23:00 dhuhr=12:04:46 asr=15:22:29 maghrib=18:46:25 isha=20:05:51 compute_us=672"
}
Two numbers define every tier: how many calls you get per month, and how many requests per second we'll accept in a burst. The per-second ceiling is the one that matters for prayer apps — it is what absorbs the five-a-day adhan spike (problem 1) without a single dropped request. The gateway enforces both today: a per-key token bucket for the rate ceiling (returning a real Retry-After if you exceed it) and a rolling monthly quota.
Priced to enter the market: the "free" prayer APIs aren't free at scale — they cap you hard. A typical marketplace prayer API hands you 500K calls a month but throttles to 1,000 requests an hour — about 0.28 req/s, a rate that collapses the moment a city hits adhan. Real paid tiers begin where those caps end. The nearest funded, hosted comparable — a general astronomy/solar API such as IPGeolocation.io — runs $49/mo for 500K calls and $249/mo for 5M, but commits no per-second guarantee. We hold every tier ~20% under that same-volume price and commit a per-second burst ceiling on top.
compute_us in every response