> ## Documentation Index
> Fetch the complete documentation index at: https://pocketmusala.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Sync Semantics

> Field rules, prayer rows, retry guidance, request ids, and API boundaries.

## 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:

```text theme={null}
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:

```text theme={null}
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.