Bring Your Own (BYO) SMS
BYO SMS routes your OTP and utility SMS through your own SMS provider's HTTP API.
Prerequisites
BYO SMS is available only with granular pricing, and your account must be entitled. Akedly grants the entitlement the first time your account is verified. An admin can revoke it afterwards, and re-verifying does not hand it back. If you do not see BYO SMS in the dashboard, contact Akedly.
Vodafone E'len pilot
Akedly can operate a managed Vodafone E'len integration for selected accounts under a pilot. Availability is by arrangement; contact us to discuss it.
Several capabilities described across the BYO SMS and utility pages work differently for a managed integration — see Managed Vodafone for the complete list.
How it works
BYO SMS supports raw-send provider APIs. Akedly composes the message body, selects a matching active, tested integration, and calls your provider's HTTP API as the transport. For OTP messages, Akedly remains responsible for generating and verifying the code.
Verify-style APIs that generate and own the code, such as Twilio Verify and Vonage Verify, are out of scope.
The mental model
| Concept | How it behaves |
|---|---|
| Registry and clones | An account-level registry holds reusable integrations. A registry integration serves every pipeline that has BYO SMS enabled. Cloning copies one onto a specific pipeline, where it takes precedence for that pipeline. Cloning is copy-by-value: edits to the registry or a clone never propagate to the other. |
| Two switches | The integration must pass its test and be active, and BYO SMS must be enabled for the pipeline — set the pipeline's routing mode to On for this pipeline (or Inherit from account to follow the account-wide default your Akedly contact sets). An active integration alone receives no traffic. |
| Coverage and catch-all | Each integration covers a set of countries; leaving it empty or selecting all countries makes it a catch-all. A pipeline clone beats the registry; then, within the winning scope, an explicit country beats a catch-all. A managed Vodafone integration is the exception — its coverage is fixed to Egypt. |
| Failure behavior | For OTP, Fall back to Akedly's SMS is the default: after a handled chain failure, Akedly sends through its own SMS providers at its normal SMS rates. Strict fails the SMS instead; utility SMS always uses strict behavior. |
When to use it
Use BYO SMS when you:
- already have an SMS provider or negotiated rates;
- need utility SMS in a country where Akedly has no utility SMS route.
For utility SMS, Akedly has no SMS route behind the BYO integration. If you need to send utility SMS to Syrian numbers, include Syria (SY) in the coverage list — possible only on an integration you build, since managed coverage is fixed to Egypt. Coverage is validated against Akedly's routable-country catalog at save time, so if SY is not in that catalog the country picker will not offer it and an explicit list will be rejected — use a catch-all instead. The catalog is Akedly-wide, not per-account. OTP routing is separate and may still use Akedly's own providers where available.
Billing at a glance
For OTP traffic, Akedly charges a resolved flat Own SMS platform fee per successful verification — a default of 0.05 EGP, with an Akedly-set account or integration override where applicable. It is not charged per message or when verification fails.
Utility SMS sent through BYO uses the same resolved flat fee, charged when Akedly bills an accepted provider submission — acceptance starts the charge rather than completing it, and an accepted submission whose billing does not settle comes back as 503 provider_outcome_reconciliation_pending instead of a success. See the Reference for fee resolution, fallback pricing, delivery receipts, and reconciliation details.
Fallback uses Akedly SMS pricing
If Fall back to Akedly's SMS sends the message through an Akedly SMS provider, Akedly charges its normal SMS rate instead of the BYO SMS platform fee.
Managed Vodafone
Everything else on these pages describes an integration you build and own. A managed Vodafone E'len integration is different: it is a customer-owned Vodafone connection driven by Akedly's server-owned adapter. You own the connection and supply its credentials; Akedly owns the request behaviour. This section is the single place that states how it differs — where another page and this one disagree about a managed integration, this one is right.
What Akedly fixes, and you cannot change
- The provider itself. It is a Vodafone integration and cannot be repointed at another provider — so "change providers" is never the answer to a managed problem.
- The request chain. A managed integration is created with no steps and the dashboard rejects any attempt to add one. Everything the build pages describe — method and URL, body format and fields, headers, query parameters, authentication, success codes, extractions, retries and the chain execution budget — is Akedly's adapter, not yours.
- Coverage. Fixed to Egypt. It cannot be widened, and there is no catch-all.
- Failure behaviour. Fixed to strict, so a failed send does not fall back to Akedly's own SMS — which is the opposite of the generic OTP default described elsewhere.
- The activation-test recipient. The test always goes to a number Akedly configures. Whatever you type in the test dialog is ignored.
What you own
- Your Vodafone credentials — exactly
accountId,passwordandsecureHashSecretKey. No other credential name is accepted, and once set none of them can be removed. - The sender name, which must be one Vodafone has approved for your account. Akedly only checks that you entered something — it cannot tell you whether Vodafone will accept it, so a name that saves cleanly can still fail at Vodafone.
- The Vodafone IP-whitelist acknowledgement, which you record yourself. Readiness requires it before the integration can be tested, and you can only record it once Akedly's egress addresses are themselves verified — so if the control is unavailable, that is Akedly's state to fix, not yours.
- The integration's name and description.
Changing the sender name or a credential deactivates the integration until it passes a test again. Changing only the name or description does not.
Getting one, and activating it
Creating and cloning a managed integration are both gated on pilot provisioning, so this is not a self-serve setup. It is also region-gated — Vodafone BYO SMS is not available in the KSA environment at all. Activation has further readiness gates: credentials, sender name, the whitelist acknowledgement, pilot enablement and account allowlisting among them; that list is not exhaustive.
Readiness is re-checked on every send, not just at activation. An active integration with a
passing test is not permanently routable — each managed send re-evaluates readiness and fails
closed if it no longer holds — a utility send then returns UTILITY_SMS_PROVIDER_NOT_READY
(provider_not_ready is the internal routing reason behind it) rather than falling back to another
route. So a managed integration can stop routing without anything about it visibly changing, and
some of what it depends on is Akedly-owned deployment state you cannot inspect or fix. If a managed
integration stops sending and its settings look correct, that is a contact-Akedly situation rather
than something to reconfigure.
In this section
- Build an integration — build an integration for your provider's raw-send API.
- Test & activate — test the integration and make it eligible to route traffic.
- Enable on pipelines & cloning — control pipeline routing and create isolated pipeline copies.
- Reference — routing, failure behavior, billing, and dashboard-visible errors.
Where it is used
- Utilities → Get set up — step 2 of the utility setup.
- Utilities → Channels — the conditions a utility SMS send has to meet.
- Utilities SMS error reference — the utility send errors related to BYO SMS.
- Pipeline Setup → BYO-SMS — attaching an integration to an OTP pipeline.