Akedly

Pipeline Setup

Configure how OTP messages are delivered to your users through customizable pipelines.

Managed Vodafone integrations differ

BYO SMS here describes an integration you build and own. If Akedly operates a managed Vodafone integration for your account, several of the capabilities described below are fixed by Akedly and are not yours to set — see Managed Vodafone.

Pipelines define the delivery channels, fallback order, and verification methods for OTP authentication. Every OTP request runs against a pipeline that controls the entire delivery flow, and the pipeline's security sections control how that traffic is protected.

Step 1: Basic Details

Navigate to OTP Pipelines in your dashboard and open a pipeline to reach its detail page.

The Active and Live / Test controls are toggle chips in the page header, not fields in this section — flipping either one saves immediately, with no separate save step.

Activation Required

A pipeline must be Active before it will accept traffic.

  • Name
    Pipeline ID
    Type
    string
    Description

    Auto-generated unique identifier for the pipeline (read-only)

  • Name
    Pipeline UID
    Type
    string
    Description

    UUID reference for API integrations (read-only)

  • Name
    Pipeline name
    Type
    string
    Description

    Internal name for your reference (e.g., "Checkout Auth Pipeline")

  • Name
    Pipeline Description
    Type
    string
    Description

    Optional description of this pipeline's purpose

  • Name
    API Version
    Type
    string
    Description

    Set when the pipeline is created and shown here as read-only. It determines which endpoint you must call for this pipeline, and which surfaces it can be used with.

  • Name
    Active
    Type
    toggle
    Description

    Header chip. Enables or disables the pipeline. Saves immediately.

  • Name
    Live / Test
    Type
    toggle
    Description

    Header chip. Switches the pipeline between live and test traffic. Saves immediately.

Changing the API version is a one-way door

The version selector stays editable on a V1.2 pipeline, so you can move it to V2 — but once a pipeline is V2 the selector is disabled and there is no way back. A V1 pipeline warns rather than switching. Treat the change as permanent, and prefer creating a second pipeline and shifting traffic to it over flipping a live one in place.

The two screenshots above are the same page on different versions: a V1.2 pipeline, whose version selector is still editable and whose Configuration rail lists every section; and a V2 pipeline, where the selector is disabled and most sections are gone. The rail is the quickest way to tell which version a pipeline is on.

The Needs attention panel beside the rail lists what is stopping the pipeline from working — an unset logging webhook URL, an inactive pipeline — so check it before debugging a failing call.

Step 2: Webhooks

Configure where Akedly sends authentication results for this pipeline.

Optional for API integrations

The Logging Webhook URL is optional when you integrate through the API — you already receive the verification result in the API response. Set it if you also want an out-of-band record of each result.

Front-end redirects depend on the surface

A plain V1.2 OTP/API integration does not need a front-end redirect because you own the UI. V1.2 hosted passkey flows and widget-attached V1 pipelines use the URL for their hosted return, while V2 pipelines require both a front-end and back-end callback URL.

  • Name
    Logging Webhook URL
    Type
    string
    Description

    Optional endpoint that receives the authentication result from Akedly's servers (e.g., https://yourapp.com/api/webhooks/akedly)

Click Save changes to persist the webhook configuration.

OTP callbacks are NOT signed

OTP results delivered to the Logging Webhook URL — on both V1.0 and V1.2 — arrive unsigned. They carry no svix-id, svix-timestamp, or svix-signature headers. Do not build signature verification on this path: a handler that rejects unsigned requests will drop every legitimate result. Verify instead by looking up the transactionID from the payload against your own record of the transaction you started, and treat the URL itself as non-secret.

Where the pipeline secret is used

The pipeline does hold a whsec_ signing secret, but it is applied only to V2 widget webhooks and Utilities webhooks — not to OTP callbacks. If you consume those, verify their signatures. For V1.2 passkeys the signed proof is the ceremony's resultToken, which you verify offline — see the V1.2 Passkeys guide. See the webhook signing guide →

Step 3: Verification Methods

Configure which channels deliver the OTP and the order in which they are tried.

Available Methods

  • Name
    WhatsApp
    Type
    priority
    Description

    Users receive their OTP through WhatsApp. Sent from Akedly's shared number unless you connect your own Business Account, which also unlocks nine destinations the shared number cannot reach.

  • Name
    Telegram
    Type
    priority
    Description

    Users receive their OTP through Telegram's official OTP verification channel.

  • Name
    SMS
    Type
    priority
    Description

    Users receive their OTP over SMS. SMS is not pinned to last position — with Custom Order enabled it can be placed anywhere in the list, including first, and the backend honours that order. To route SMS through your own provider instead of Akedly's, see BYO SMS.

  • Name
    Email
    Type
    priority
    Description

    Listed in the UI under Optional through API. Used when an email address is supplied in the API request.

Priority Configuration

  • Name
    Priority Order
    Type
    toggle
    Description

    Enable Custom Order to arrange the methods yourself instead of using the default order

  • Name
    Add Method
    Type
    button
    Description

    Add additional verification methods to the pipeline

Drag the handles to reorder methods, or use the arrow buttons to move a method up or down.

BYO-SMS

Route this pipeline's SMS traffic through your own SMS provider instead of Akedly's senders. Your account-level integrations are listed here with a Clone to this pipeline action; a cloned integration is consulted before your account-level ones, so a pipeline can override the account default for a country.

The setting is three-state — on, off, or inherit the account default — and the section only appears for accounts entitled to BYO SMS.

Building an integration, its country routing, and what happens when your provider's API fails are covered in BYO SMS.

Destination Countries

Restrict which countries this pipeline is allowed to send to. Requests targeting a country outside the allowed set are rejected, which limits the blast radius of a leaked API key.

Dev Mode

Dev Mode mints a test phone-and-OTP pair and holds it for one hour. Requests for that number skip rate limiting and the circuit breaker, so you can iterate without tripping the pipeline's own protections. It also exposes Bypass PoW and Bypass Turnstile toggles. Changes here save immediately.

Rate-limit and breaker bypass is scoped to the test number

Only traffic matching the test pair skips those two controls — every other request to the pipeline stays fully rate-limited and breaker-protected for the whole hour. The Bypass PoW and Bypass Turnstile toggles are the exception: those are pipeline-wide while the window is open. Do not leave Dev Mode on for a pipeline serving real traffic.

PoW Security

Proof of Work (PoW) makes each request pay a small computational cost before an OTP is sent. On a V1.2 pipeline the enable switch is rendered locked on, so this section tunes PoW rather than switching it off.

Adaptive Difficulty is on by default: the system raises and lowers the difficulty automatically based on observed traffic, so you do not need to pick a fixed value.

Which sections appear depends on the API version

Dev Mode, PoW Security, Turnstile, Rate Limiting and Circuit Breaker are shown only on V1.2 pipelines. A V1 or V2 pipeline has none of those sections. Passkeys appears in the pipeline editor on V1.2 pipelines. For a V2 pipeline, turn on Passkeys from the linked widget instead. BYO-SMS appears on every version, but only for accounts entitled to it, and Destination Countries appears on every version — the country gate is enforced on the shared send path, not a version-specific one.

Turnstile

Optional Cloudflare Turnstile bot protection for this pipeline, at no additional cost. Enable it to require a Turnstile challenge alongside Proof of Work.

Rate Limiting

Caps request volume at three levels — per phone number, per IP address, and per pipeline. Tighten these to match your real traffic shape rather than leaving headroom an attacker can use.

Circuit Breaker

Automatically suspends the pipeline when traffic exceeds a configured multiple of the rate limits, containing a spike or an abuse burst before it drains your balance.

Passkeys

Let returning users verify with a device passkey instead of receiving an OTP.

Passkeys are available on both surfaces

For a V1.2 pipeline, you turn on Passkeys in the pipeline editor's Passkeys section. For a V2 pipeline, you turn on Passkeys in the linked widget's Passkeys section; the setting is stored on the pipeline in both cases and you save the V2 setting with the widget's Save Changes button. The widget refuses the setting unless its linked pipeline is V2. If your account is not enabled for Passkeys, the switch still appears but is greyed out and not usable, with a request-access prompt beside it.

Next Steps

Your next step depends on the pipeline's API version:

  • V1.2 (the default) — this is an API-only pipeline. Call the REST endpoints directly with the pipeline's API key; it cannot be attached to a widget, and the backend rejects the attempt with "V1.2 pipelines cannot be attached to widgets."
  • Widget integrations — a widget accepts a V1 or V2 pipeline; V1.2 is the one version it refuses. Use a V2 pipeline for new widget work, then follow Widget Setup.

Was this page helpful?