> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Troubleshoot SMPP_BACKEND_UNAVAILABLE (503) > Resolve the SMPP_BACKEND_UNAVAILABLE 503 returned by SMPP credential issuance and rotation when the tenant database schema, the organization encryption key, or the Jasmin reconciler queue is unavailable — the control-plane failure you hit before any bind attempt is possible. # Troubleshoot `SMPP_BACKEND_UNAVAILABLE` (503) Issuing or rotating an SMPP credential can fail with `503` and code `SMPP_BACKEND_UNAVAILABLE`. This happens on the **control plane** — the credential create or rotate endpoint — before the credential ever reaches the SMPP edge. No bind was possible, so no wire-level error code could have returned. Keep the two failure classes separate: * **Control-plane 503** — `POST /messaging/smpp/credentials` or `POST /messaging/smpp/credentials/:id/rotate` answered `SMPP_BACKEND_UNAVAILABLE`. Work this page's dependency checklist. * **Wire-level reject** — the credential exists and the bind itself returned a non-zero `command_status` (`ESME_RINVPASWD`, `ESME_RINVSYSID`, `ESME_RINVBNDFMT`, ...). That is a different class; decode it on the [SMPP bind rejects and command\_status codes](/troubleshooting/smpp-bind-and-command-status-codes) page instead. If you are reading a lookup, confirm which class it came from before changing anything. ## The three control-plane dependencies Issuance and rotation write the credential into your tenant schema, seal the password under your organization's encryption envelope, and — for BYO Jasmin carriers — queue the related changes on the Jasmin reconciler. Three dependencies must all be available; a failure on any of them is folded into this 503. Check them in order: | Dependency | Why a failure surfaces | Where to look | | --------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | | Tenant database schema | The credential row is written to your tenant schema; a schema still provisioning or mid-migration refuses the write. | The sibling | | [`TENANT_SCHEMA_INCOMPLETE`](/troubleshooting/tenant-schema-incomplete-503) | | | | runbook — note timing of org creation or a rollout window. | | | | Organization encryption key | The password is sealed with the platform envelope encryption; when the org encryption harness is unavailable, issuance refuses instead of storing material it cannot protect. | The sibling | | [BYOK key unavailable runbook](/troubleshooting/byok-key-unavailable) | | | | if your org enforces customer-managed keys; otherwise treat it as a | | | | platform-side fault and escalate. | | | | Jasmin reconciler | For BYO Jasmin carriers, the write mixes server-side steps the reconciler must be able to apply; an unavailable reconciler queue blocks the provisioning path. | The | | [SMPP edge model](/concepts/smpp-edge-model) page explains what the | | | | reconciler applies; check the dashboard error banner for a queue | | | | depth warning if one is shown. | | | A request that names none of them explicitly still fails the same way — the three preconditions are checked unconditionally, so the wire format of the failure cannot tell you which dependency was down. Use the schedule of what you changed (org creation, rotation, a recent BYOK registration) to pick the first row to check. ## Retry-safety `SMPP_BACKEND_UNAVAILABLE` is in the **transient 5xx class** — it is safe to retry: * Wait, then retry the same issuance or rotation call with a short backoff. A retry hangs where it can; nothing is rolled back into a broken state. * If your client library sends or parses a `Retry-After` header on 5xx responses, honor it. The value names the platform's expected recovery interval for the dependency it detected down. * **Never delete partial state yourself.** A failed issuance leaves no credential row behind, and a failed rotation keeps the previous password valid — do not issue a delete to "clean up," because there is nothing to delete, and for rotation a delete would revoke credentials your ESME client still needs. What must not be retried blindly: a 503 that persists for more than a few minutes is a dependency outage, and a tight loop only builds noise on an unavailable queue — prolong the backoff and escalate when the escalation thresholds below are reached. ## When rotation is safe versus when the 503 implies an outage Rotation of an existing credential is safe to attempt whenever the control-plane is healthy — the old password stays valid until a new one is issued, so an abortive rotate attempt breaks nothing. The 503 does imply one of the dependencies is unavailable **now**, so: * **First issuance** — if provisioning a brand-new org fails, suspect the tenant schema row: this matches the provisioning window the [`TENANT_SCHEMA_INCOMPLETE`](/troubleshooting/tenant-schema-incomplete-503) sibling covers, and a plain retry after seconds is the right move. * **Rotation on a mature org** — on an org that issued credentials before, a schema-related 503 is unusual; suspect the encryption-key or the reconciler queue row instead, and the escalate path below applies from the first failure. * **Rotation under BYOK enforcement** — if your org enforces a customer-managed key, the envelope depends on that key being decryptable; work the [BYOK key unavailable runbook](/troubleshooting/byok-key-unavailable) first. ## When to escalate Open a support ticket when one of these holds: * Retries of the same endpoint kept failing for **15 minutes** on a mature org, or one hour on an org still inside the provisioning window. * Both `issue` and `rotate` fail with the same 503 — a schema cause that broad is never a per-call race. * Your org enforces BYOK and the [`GET /api/v1/compliance/byok`](/compliance/byok-customer-managed-keys) read shows `active` + `enforced`, yet issuance still 503s on the encryption path. Include your **organization ID** (Settings → Organization, or `organizationId` from `GET /api/v1/me`), the **request ID** from `meta.request_id` on one failing response, and whether the call was issuance or rotation. ## See also * [SMPP bind rejects and command\_status codes](/troubleshooting/smpp-bind-and-command-status-codes) — the wire-level cousins: bind rejects and `ESME_*` submit nacks * [Tenant schema incomplete](/troubleshooting/tenant-schema-incomplete-503) — the sibling control-plane 503 on any endpoint * [BYOK key unavailable](/troubleshooting/byok-key-unavailable) — org-encryption dependency when customer-managed keys are enforced * [SMPP edge model](/concepts/smpp-edge-model) — the reconciliation model the Jasmin queue dependency comes from * [Troubleshoot system 5xx](/reference/troubleshooting-system-5xx) — the generic-transient layer every 503 sibling shares