Skip to main content

​
Profile Fields

The profile endpoint accepts only approved public mosque fields:
  • communityName
  • address
  • latitude
  • longitude
  • timeZoneId
  • isOnlineOnly
  • status
  • message
  • donationLink
  • prayerCalculationParameters
Unknown fields are rejected. The Developer API cannot change ownership, admins, verification, entitlement, moderation state, payment configuration, or mosque lifecycle actions.

​
Prayer Rows

Prayer times use manual rows. Each row has:
  • id
  • prayerKey
  • adhanTime
  • iqamahTime
  • createdAt
Supported prayer keys: 
fajr, sunrise, dhuhr, asr, maghrib, isha, midnight, tahajjud, duha, jummah, eid
Times may be sent as HH:mm or h:mm am/pm. PocketMusala normalizes spacing and casing. Examples: 
04:21
4:21 am
13:15
1:15 pm
Multiple rows with the same prayerKey are allowed. Use this for multiple Jummah times.

​
Weekly Replacement Strategy

There is no public destructive bulk-replace endpoint. To replace weekly prayer times safely:
  1. GET /v1/mosques/{mosqueId}/prayers.
  2. Match rows by prayerKey, adhanTime, and iqamahTime.
  3. POST missing desired rows.
  4. PATCH rows that should keep the same id but change time values.
  5. DELETE rows that should no longer appear.
This keeps a failed weekly job from removing every prayer row in one call.

​
Retries And Request Ids

Send a unique X-Request-Id for every request. Store it with your integration logs. The current API does not guarantee server-side de-duplication by Idempotency-Key. Make your sync job retry-safe by retrying the same request body, reading current state before replacement-style work, and avoiding concurrent weekly jobs for the same mosque. Recommended retry pattern:
  • Retry transient network errors and 500 responses with exponential backoff.
  • Do not blindly retry 400, 401, 403, or 404; fix the payload, key, or mosque id first.
  • If a request may have succeeded but the client timed out, read the current resource before sending another write.

​
Rate Limits

The MVP is intended for low-frequency partner sync. Treat 60 requests per minute per integration as the default planning budget unless PocketMusala provides a different limit for your key. If a future response returns 429 Too Many Requests, pause the sync and retry after the next minute boundary.