Overview. Before you can send an email, Relay needs a sender — the name and address recipients will see. There are two ways to get one, and you can use both. Open Channels → Email → Sender setup and choose Set up email sending.

Which one should I pick?

• Use a Relay address — no DNS, no IT ticket, live within the minute. Relay creates Your Brand <yourbrand@mail.<relay-domain>> on a domain it already owns and has signed with DKIM. Best for your first send, a pilot, or transactional mail where the address matters less than shipping.
• Use my own domain — recipients see your brand in the address itself, which is better for deliverability and trust. Costs about ten minutes and three DNS records. Best for marketing you intend to keep sending.

Steps — a Relay address

1. Choose Use a Relay address.
2. Fill in Name customers will see (your brand — this is the name in the inbox) and Address (the part before the @; Relay suggests one from your brand name and will offer an alternative if it's taken).
3. Set Where should replies go? to a mailbox a human actually reads. Replies do not come back into Relay — they land in that inbox.
4. Fill in Business address (for the footer). This is not optional for marketing: a promotional send from a sender with no postal address is refused. See Sender branding & the legal footer.
5. Check the Preview line — it shows exactly what the recipient sees — then Save.

Steps — your own domain

Choose Use my own domain and follow Verify your own sending domain, which walks through the three records and what to do when they aren't found.

Best practices

• Use a subdomain for your own domain — mail.yourcompany.com, not yourcompany.com — so marketing volume can never affect your staff's normal company email. The screen suggests this.
• One sender per brand. An account that sends as two brands should have two senders, because branding and the legal footer belong to the sender, not the account.
• Mark the one you send most from as default; campaigns and automations pre-select it.

Troubleshooting

• "Email sending is not switched on for this deployment yet" → the channel is off for your site, or SES is not configured on it. Nothing you can change from the portal; contact your Relay account team.
• "Not available on this deployment yet" under Use a Relay address → the shared domain isn't offered on your site. Use your own domain instead.
• Your chosen address is taken → Relay suggests a free alternative and fills it in for you; accept it or type another.
• "Finish sender setup to start sending" on Templates or Campaigns → you have a sender that is not verified yet, or none at all. Come back here.
• You can't delete a sender → deleting is blocked while a campaign still references it. Repoint or delete those campaigns first.

Related: Verify your own sending domain · Sender branding & the legal footer · Build an email template

Overview. Sending as hello@yourcompany.com means proving to the receiving mail servers that you own the domain. You do that by adding three CNAME records at whoever manages your DNS. Relay generates them, shows them with copy buttons, and then watches for them — you don't have to come back and press anything.

Steps

1. Channels → Email → Sender setup → Set up email sending → Use my own domain.
2. Enter the Sending domain. Use a subdomain — mail.yourcompany.com — so this never affects your normal company email.
3. Fill in Name customers will see, Default from address, Where should replies go? and Business address (for the footer), then Show me the records.
4. You now have three rows — Type, Host / Name, Value / Points to — each labelled DKIM (proves the email is really from you). Use Copy all, or the per-field copy buttons.
5. Add them at your DNS provider. The screen has step-by-step guides for GoDaddy, Cloudflare, Namecheap and Other hosts — open the one you use.
6. Come back and press I've added them — check now, or simply leave. Relay re-checks in the background and the status chip flips to Verified on its own.

What the status chip means

• Waiting for DNS — records not visible yet. Normal for the first 5–30 minutes.
• Verified — done. The screen tells you "You can now send as …" and offers Create your first email.
• Retrying — a temporary lookup failure at the DNS level. Relay keeps trying; no action needed.
• Not found — Relay looked and the records are not there. Work through the troubleshooting list below.

Troubleshooting

• The Host field is wrong. The most common cause by far. Some providers append your domain automatically, so pasting the full host creates …_domainkey.mail.yourcompany.com.mail.yourcompany.com. Relay shows the short form to use instead — "If your host auto-adds .yourdomain, enter only: …".
• Cloudflare: the orange cloud must be OFF. Proxying a DKIM CNAME breaks it. The row has to read DNS only.
• Wrong record type. All three are CNAME — not TXT, not A.
• You added only one. All three must be present; DKIM rotates between them.
• Still nothing after 72 hours → you may have added the records to a different zone than the one that actually serves the domain (common when a domain was transferred). Confirm with whoever manages your DNS which provider is authoritative.

Related: Set up email sending · Add a bounce (MAIL FROM) domain

Overview. By default, bounce notifications for your email use a Relay-owned return path. That works, and most accounts never change it. Setting your own bounce domain makes the return path match your brand too, which is what DMARC calls SPF alignment — worth doing if you plan to publish a strict DMARC policy.

Steps

1. Open Channels → Email → Sender setup and expand the verified sender you want to change.
2. Open Set up bounce domain.
3. Relay shows two more records, labelled Bounce handling (MX) and Bounce handling (SPF). Add both at your DNS provider, exactly as with the DKIM rows.
4. The expanded sender then shows Bounce domain … — status: …. It moves to success on its own once the records resolve.

Best practices

• Use a subdomain of the domain you already verified — a bounce subdomain of mail.yourcompany.com, not of an unrelated domain.
• The MX record is what receives the bounce. Don't point it at your own mail server; use the value Relay gives you.
• If you publish DMARC, do it after this shows success, and start at p=none so you can read the reports before enforcing.

Troubleshooting

• Status stays pending → the same Host-field trap as DKIM. Check whether your provider appended the domain.
• Status is temporary_failure → a transient DNS problem. Relay keeps re-checking; nothing to do.
• Status is failed → the records are wrong or on the wrong zone. Re-open the panel, re-copy both rows, and confirm the zone.
• Bounces still look like they come from Relay → expected until the status reads success; the switch is not partial.

Related: Verify your own sending domain · Unsubscribes, bounces & complaints

Overview. Email content lives in reusable templates with the same draft → review → approved lifecycle as SMS. Open Channels → Email → Templates and create one. The editor has two modes: Design (drag blocks; no HTML knowledge needed) and HTML (paste your own).

Steps

1. Pick a Type: Transactional, Promotional or System. This drives consent and the footer rules — promotional respects marketing opt-out, transactional doesn't.
2. Write the Subject line and the Preview text (the grey line the inbox shows after the subject — leave it empty and the inbox will grab your first sentence instead).
3. In Design, add blocks: header, heading, text, image, button, divider, spacer, footer. Select any block to open Block settings for its colour, alignment and size.
4. Personalise with the same tokens as SMS — {first_name} and other Contact fields. The Personalisation panel lists what's available and lets you set a fallback for contacts missing that field.
5. Set Direction if needed. Relay infers it from the language and you can override it. Alignment is logical, so an Arabic template flips correctly rather than needing a separate layout.
6. Check Live preview at both widths with Preview as, and pick which sender to preview under — branding is per sender, so this is what the recipient actually receives.
7. Send test to yourself. This works on an unsaved draft, so you can iterate before committing.
8. Save as draft, then Submit for review. An admin sees Approve / Reject; a rejection comes back with Why is this rejected? so you know what to change.

Using your own HTML

• Switch to HTML and paste. Relay sanitises server-side: "Scripts, iframes and forms are removed for safety." Tables and inline styles — the things email actually needs — are preserved.
• You must include the unsubscribe token where you want the link to appear. The editor tells you this and will flag it under Fix before submitting if it's missing.
• Design output is a responsive 600px table-based email that survives Outlook. If you bring your own HTML, that's on you — test it.

Best practices

• Add a language variant rather than duplicating a template: + Add language keeps subject, preheader and body per locale under one template, with one marked default.
• Always set fallbacks for tokens used in the subject line. "Hi , your order" in an inbox is worse than no name at all.
• Keep one clear call to action. The button block exists so you don't have to rely on a bare link.

Troubleshooting

• "Set up a sender" → no verified sender yet. See Set up email sending.
• "Fix before submitting" → the editor lists exactly what's blocking. Most often a missing unsubscribe token or a token with no fallback; Add missing tokens inserts them for you.
• Editing an approved template. Allowed, but "Saving returns this email to Draft" and "It will need approving again before it can be sent." The editor names the campaigns and automations that "are using it right now and will stop until it is re-approved" — read that list before you save.
• Arabic renders left-to-right → set Direction to RTL explicitly rather than relying on inference.

Related: Sender branding & the legal footer · Send an email campaign · Create & submit an SMS template

Overview. Logo, colours, font and the legal footer belong to each sender identity, not to your account. An account that sends as two brands keeps two sets, and the unsubscribe page a recipient lands on is branded as the sender they actually heard from. This is also where the one hard requirement lives: a promotional email cannot be sent from a sender with no postal address.

Steps

1. Open Channels → Email → Sender setup and expand the sender.
2. Set the logo, primary colour, background colour and font. These are what the block editor renders with, so a template previewed under this sender looks like the real thing.
3. Fill in the footer's company name and postal address. If you saw "Add your business address" anywhere in the product, this is what it meant.
4. Open a template and use Preview as against this sender to confirm.

Why the postal address is mandatory

• It is a legal requirement for commercial email in the markets Relay serves — KSA's CST anti-spam rules and Egypt's PDPL among them — and a hard requirement of the major inbox providers.
• Relay enforces it rather than documenting it, because a send that gets your domain blocklisted is not recoverable by apologising afterwards.
• Transactional and System emails are not blocked by this. Only Promotional.

Best practices

• Use a real, monitored postal address. A PO box is acceptable in most jurisdictions; an invented address is not.
• Set branding once per sender before you write templates, so no one has to re-check a dozen templates afterwards.
• If a template has no footer block, Relay appends one. That's a safety net, not a design decision — add the footer block yourself so you control where it sits.

Troubleshooting

• A promotional campaign won't launch and names the sender → the postal address is missing on that sender. Branding is per sender, so filling it in on another one doesn't help.
• The unsubscribe page looks wrong → it is branded from the sender, so check the sender's branding, not your org profile.
• The logo doesn't appear → some inboxes block remote images by default. Keep your brand name in the header block as text too.

Related: Build an email template · Unsubscribes, bounces & complaints · Organization profile

Overview. An email campaign is built in the same multi-step builder as SMS and WhatsApp — pick the channel, pick the audience, pick the content, review, launch. What's specific to email is the subject line, and that you can A/B test it.

Steps

1. Campaigns → New Campaign and choose Email as the channel. (No Email option? See Set up email sending.)
2. Choose the sender to send as. This decides the from-address, the branding and the footer.
3. Pick the audience — a segment, a saved search, or an upload. Contacts with no email address are excluded automatically, so an email audience and an SMS audience of "everyone" are legitimately different sizes.
4. Pick an approved email template. Drafts and pending templates don't appear.
5. Optional — add a B variant to test the subject line, and a control holdout to measure what the send actually added over sending nothing. See A/B test with a control holdout for how to read the result.
6. Schedule or send now. Quiet hours and frequency caps apply to email exactly as they do to the other channels.
7. Review, then launch. Read any warning on this step rather than clicking through it.

Best practices

• Test the subject line first. It moves open rate more than anything inside the email, and it is the cheapest thing to change.
• Send yourself a test from the template editor before you launch to an audience. The builder's preview is not a substitute for seeing it in a real inbox.
• Warm up gradually on a newly verified domain — a few thousand at a time, watching the bounce and complaint rates in the Email Explorer — rather than sending your whole list on day one.
• Keep a permanent holdout on recurring campaigns. Without it you are reporting revenue that would partly have arrived anyway.

Troubleshooting

• Launch is disabled → most often the sender has no postal address and the template is promotional (fix that here), or your account is in a billing grace state (see what that means). The block always says which.
• Your audience is smaller than expected → contacts without an email address are excluded. Check the contact base, not the segment definition.
• The template isn't in the list → only approved templates can be sent. Check its status in Channels → Email → Templates.
• Sent but nothing arrived → go to the Email Explorer and look at the per-message timeline. Suppressed and bounced are different problems with different fixes.

Related: Build an email template · The Email Explorer · A/B test with a control holdout (SMS) · Schedule & timezones

Overview. Channels → Email → Explorer is the record of every email Relay sent for you and the outcome the receiving server reported back. It is the first place to go when someone says they didn't get an email.

Steps

1. Set a date range, then Search by recipient address or Subject.
2. Narrow with Status, Source (Campaign, Automation, API or Test) and Sender / All senders, then Apply.
3. Read the seven tiles across the top: Sent, Delivered, Opened, Clicked, Bounced, Complaints, Unsubscribed.
4. Click a row for the detail panel — the full Timeline, the bounce type and sub-type with the provider's own diagnostic text, open and click counts, and the last URL clicked.
5. Export the current filter result with CSV export.

What each status means

• queued — accepted by Relay, not yet handed to the provider.
• sent — handed over. Not proof of arrival.
• delivered — the receiving server accepted it. Still not proof a human saw it.
• bounced — rejected. A hard bounce (no such mailbox) suppresses the address automatically; a soft bounce (mailbox full) may succeed later.
• complained — the recipient pressed "spam". The most expensive outcome there is; see why.
• suppressed — Relay deliberately did not send, because the address previously hard-bounced, complained, or unsubscribed. Working as intended.
• deferred — the receiving server asked us to try later. Usually resolves itself.
• failed — could not be sent at all. The detail panel says why.

Best practices

• Watch Bounced and Complaints after every large send, not monthly. They are the two numbers that decide whether your future email arrives.
• Treat opened as directional only. Inbox privacy features both inflate and hide opens; clicks are the more honest signal.
• When a customer reports a missing email, search their address first and read the timeline before assuming anything.

Troubleshooting

• "No emails in this range." → widen the date range; the default window is narrow.
• A contact shows suppressed every time → they are on the suppression list. That is deliberate and you should not work around it; see Unsubscribes, bounces & complaints.
• Delivered but the customer insists nothing arrived → delivered means the server accepted it. Ask them to check spam, and check whether your domain is verified (here) — unauthenticated mail lands in spam far more often.
• Bounce rate climbing → stop sending to the affected list and clean it. Support can see the same view across tenants and will act before the provider does.

Related: Unsubscribes, bounces & complaints · Send an email campaign · Find & export message traffic

Overview. Email deliverability is mostly reputation, and reputation is mostly these three numbers. Relay handles the mechanics for you — every email carries an unsubscribe link and one-click headers, and addresses that bounce or complain are suppressed automatically. What you control is the list you send to.

What Relay does for you

• An unsubscribe link on every email. If your template has no footer, Relay appends one. The link is a signed token with no expiry, so it keeps working long after the send.
• One-click unsubscribe headers (RFC 8058 List-Unsubscribe and List-Unsubscribe-Post), which is what Gmail and Yahoo require of bulk senders. You meet that requirement by default — there is nothing to switch on.
• Automatic suppression. A hard bounce or a spam complaint adds the address to your suppression list and Relay stops sending to it. Those messages appear as suppressed in the Explorer.
• A complaint-rate guard on Relay-address senders. If complaints climb, Relay disables that sender before it can damage the shared domain other customers also send from.

What you control

1. Only send to people who gave you their address. Purchased and scraped lists are the single fastest way to lose a sending domain, and no technical setting compensates.
2. Clean before big sends. Segment out addresses that have not opened or clicked in a long time rather than mailing your whole history.
3. Make unsubscribing easy. A visible unsubscribe link costs you far less than a spam complaint, which damages delivery for everyone on your list.
4. Match content to the type. Sending marketing from a Transactional template to dodge opt-out is both a policy breach and a complaint generator.
5. Watch the two rates in the Explorer after every send.

The numbers that matter

• Bounce rate — keep it low and falling. A rate above a few percent is a list-quality problem, and sustained high bounces can pause sending for the whole deployment, not just your account.
• Complaint rate — the tighter of the two limits by far. It takes very few complaints per thousand to cause trouble, which is why "one more send to the old list" is rarely worth it.
• Unsubscribe rate — not a reputation problem. A rising rate is a relevance problem: you are mailing the wrong people or too often.

Troubleshooting

• Your Relay-address sender was disabled → the complaint-rate guard fired. Review what you last sent and to whom before asking for it back; the same send will trip it again.
• Delivery got worse after a big send → you likely mailed a cold segment. Go back to recently engaged contacts for a while and rebuild.
• A customer says they unsubscribed but still received email → check the message Type. Transactional and system emails are not governed by marketing opt-out, and shouldn't be.
• You need an address removed for a data-erasure request → that's a contact-level deletion, not a suppression change. Raise it with support.

Related: The Email Explorer · Sender branding & the legal footer · Deliverability & compliance in MENA

Overview. When you buy or change a plan, the checkout offers two ways to pay, and the one you pick is remembered for every future renewal. Open Billing & Plans, choose a plan from Available Plans, and look for Pay with.

Wallet

• Offered only when your balance covers the plan fee. When it does, it is pre-selected and the plan activates in the same request — no redirect, no waiting for a payment notification.
• When it doesn't, the option is disabled and tells you the exact shortfall: "Balance … does not cover this plan. Top up … to pay from your wallet."
• Your wallet is also what pay-as-you-go usage draws from, so leave headroom above the plan fee rather than topping up to exactly the price.

Card

• The hosted PayTabs page — Relay never sees your card number.
• Choose Save this card and it becomes the token used for Automatic renewal. You can change it later with Update Card, or add one ahead of time with Add Card when the screen shows No card on file.
• Auto-renew can be switched off at any time.

Steps — top up your wallet

1. On Billing & Plans, find Wallet Balance and choose Top up by.
2. Enter an Amount within the limits shown, and confirm. This is the same PayTabs hosted page as checkout.
3. The balance is credited once the payment is confirmed — not at the moment you close the page. Use View ledger to see the transaction.
4. Optional: turn on Auto-recharge so usage never stops for an empty wallet.

What happens at renewal

• The choice is honoured. A wallet-funded subscription is renewed by debiting the wallet — it is never charged to a card it doesn't have.
• Wallet renewals still work when the card gateway is unavailable or online payments are switched off for your deployment, because they never touch PayTabs.
• A wallet renewal that the balance can't cover is treated exactly like a declined card: it enters the announced retry-and-grace ladder with "insufficient funds" as the reason. See When a renewal fails.

Best practices

• Keep Auto-recharge on if you use pay-as-you-go. It is the cheapest insurance against a stopped campaign.
• If your finance team pays by transfer, fund the wallet and pay from it — you avoid card expiry as a failure mode entirely.
• Check Due now (prorated) on a mid-cycle plan change before confirming; it is rarely the full sticker price.

Troubleshooting

• Wallet is greyed out at checkout → the balance doesn't cover the fee. The option itself names the amount to top up.
• You paid but the plan didn't activate → a card payment activates on the confirmed payment notification, not on redirect. Give it a moment, then re-open Billing & Plans. If it's still not active, check Invoice History before paying again — retries are idempotent, so you will not be charged twice for the same attempt.
• "No card on file" and a renewal is due → use Add Card, or top up the wallet and let the renewal take it from there.
• An add-on purchase failed with a prompt to top up → add-ons bill from the wallet, not the card.
• No plans listed ("No plans available at the moment") → nothing you can fix in the portal; contact support.

Related: Billing & plans · When a renewal fails — grace period & read-only

Overview. If an automatic renewal can't be collected — a declined card, an expired card, or a wallet without enough balance — you are told, repeatedly and with dates, before anything stops. Sending keeps working for a fixed grace period first. Nothing is ever deleted.

The three stages

1. Grace period opens — sending still works. The first failed charge shows an amber banner reading "Payment failed — N days left to fix it", with the detail: "We could not collect … for your subscription. Sending still works until <date>. After that your workspace becomes read-only and all campaigns, automations and test sends stop." That deadline is fixed when the first charge fails, so the banner, the email and the API all quote the same day.
2. Each automatic retry. Relay retries on a schedule and raises a critical notification each time, naming the amount, the decline reason in plain language, the next retry date and the days of grace remaining. These notifications ignore your quiet hours — deliberately.
3. Read-only. If the ladder runs out, a red banner appears that cannot be dismissed: "Workspace is read-only — sending is paused." Campaigns, automations, WhatsApp and test sends stop. The detail spells out what survives: "Nothing was deleted: your contacts, templates and wallet balance are intact."

Where you will see it

• A banner on every screen, not only Billing. Amber is dismissible for the browser session; red is not, because a hidden banner is how people end up confused at a disabled Launch button.
• In the campaign builder — a notice at step 1 and the Launch button disabled with the reason.
• In the Test Center — before you compose, not after you press send.
• On any blocked send, including through the API: the response carries a machine error code and a human message, and the UI shows the message.

How to recover

1. While the banner is amber — press Pay now. Settle the charge with a card, or top up the wallet if that is your payment source. A successful charge clears the dunning trail, restores full access immediately, and sends a "payment received — sending resumed" confirmation.
2. Once the banner is red — the button says Select a Plan, and that is the actual step. The subscription has expired, not merely gone unpaid, so paying the old invoice does not bring it back. Choose a plan again from Available Plans.

Best practices

• Don't dismiss the amber banner and move on. Dismissing hides it for the session only; it does not pause the deadline.
• Make sure billing notifications reach someone who can actually pay — check Settings → Notifications. Billing alerts are mandatory and cannot be switched off, but they can go to the wrong person.
• A card that is about to expire is the most common cause. Update it with Update Card before the renewal date, not after.
• If renewals keep failing, switch to wallet funding — see Paying for a plan.

Troubleshooting

• "I paid — why am I still blocked?" → you are almost certainly past read-only, where the subscription is expired. Use Select a Plan.
• The banner won't go away → red is intentionally not dismissible. It clears when the account is paid and active.
• The decline reason is unclear → the notification carries it in plain language ("insufficient funds", "the saved card has expired"). For anything else your bank is the only one who can tell you why.
• You were never notified → check Settings → Notifications for the address on file, and your spam folder. Critical billing notifications bypass quiet hours, so they were not held back.
• Read-only and you need a contact export urgently → reads still work. Your data is not locked, only sending.

Related: Paying for a plan — wallet or card · Billing & plans · Notifications

Overview. Relay can send and check one-time passcodes for your own app — sign-in codes, phone-number confirmation, high-value transaction checks — without you building any OTP infrastructure. Relay generates a secure, time-limited code, sends it on the channel you choose, and gives you one API call to check it. Open Solutions → Verification → Get Started.

Steps

1. Under Get started — pick a channel, choose one of the four ready-made templates: Verify by SMS, Verify by WhatsApp, Verify by Email, or WhatsApp with SMS fallback.
2. Press Activate. Relay creates the flow and opens it in the automation builder.
3. In the builder, configure the generate OTP step — code length, how long it stays valid, and how many wrong attempts are allowed — then the message itself and the sender to send from. The code is available to the send step as {otp}.
4. Publish the automation, and copy its ID from the URL.
5. From your app, call the trigger with the recipient. You get back an enrollmentId — keep it, it is the handle you check the code against.
6. When the user types the code, check it — see Check a code from your app.

Which channel should I use?

• SMS — the default. Works on every handset with no app, and users expect it. Needs a registered sender ID in the GCC.
• WhatsApp — cheaper at volume in many markets and better delivery where SMS is unreliable, but only reaches users who have WhatsApp.
• WhatsApp with SMS fallback — tries WhatsApp, falls back to SMS for anyone unreachable. Usually the best outcome per riyal spent; start here if you are unsure.
• Email — for sign-ups where you have an address and no phone number. Slower to arrive and more likely to be filtered.

Best practices

• Six digits and a short expiry (a few minutes) is the norm. Longer codes annoy users; longer expiry widens the window for an attacker.
• Keep max attempts low — three is typical. The lockout is what stops someone guessing a 6-digit code.
• Say the brand name in the message so a user can tell a real code from a phishing one, and never include a link in an OTP message.
• Verification traffic is transactional, so it is not held by quiet hours or marketing opt-out — which is correct, but it also means you should not use this flow to send anything promotional.

Troubleshooting

• "No verification templates yet — they'll be seeded by ops, check back shortly." → the starter templates haven't been provisioned for your account yet. Nothing to fix from your side; contact your Relay account team if it persists.
• The code never arrives → check the delivery log for that channel (SMS, WhatsApp or Email). An OTP is an ordinary message as far as delivery is concerned.
• You don't see Verification in the sidebar → the module isn't enabled for your deployment.
• WhatsApp OTP isn't delivered → an authentication-category template must be approved by Meta first; see Message template categories & the approval process.

Related: Check a code from your app · Verification analytics · Create an app & credentials

Overview. Verification is two calls. The first sends a code and hands you a handle; the second checks what the user typed against it and answers immediately. Both use an API key — see Create an app & credentials.

1 · Generate & send

Trigger the verification automation with the recipient:

• POST /api/v1/automations/<AUTOMATION_ID>/trigger
• Headers: Authorization: Bearer rly_<API_KEY> and Content-Type: application/json
• Body: the recipient — for example { "phone": "+9665XXXXXXXX" }
• Returns 201 with { "enrollmentId": "…", "status": "active", "contactId": "…" }

2 · Verify (synchronous)

• POST /api/v1/automations/verifications/<enrollmentId>/check
• Same auth headers; body { "code": "123456" }
• Returns immediately with { "status": …, "remaining": 3, "channel": "sms" }

What each status means

• approved — correct code. Let the user through. The code is single-use, so a second check on the same handle will not approve again.
• denied — wrong code, and attempts remain. Show the user the error and let them retry; remaining tells you how many tries are left.
• expired — the code was right or wrong but is past its validity window. Send a new one.
• max_attempts — too many wrong tries; this handle is locked. Start a new verification rather than retrying.
• 404 "Verification not found" — the handle is unknown, or old enough to have been purged. Treat it exactly like expired: start again.

Security you get for free

• Codes are generated with a cryptographic random source, stored only as a hash, and compared in constant time — a stolen database dump does not reveal live codes.
• Single-use, time-limited, and attempt-locked by the values you configured.
• Tenant-scoped: a handle from one account cannot be checked with another account's key.
• Per-handle throttling, so the check endpoint cannot be hammered.

Best practices

• Never send the code back to your own front end, and never log it. Check server-side only.
• Rate-limit your own "resend code" button. Each resend costs a message and trains users to expect several.
• Treat 404 and expired identically in your UI — "that code has expired, here's a new one" — rather than exposing the distinction.
• Use a dedicated app and API key for verification so its traffic and limits are isolated from your marketing sends.

Troubleshooting

• 401 / 403 → wrong or revoked key, or the key doesn't have access to this app. Check Developer Tools → API & Integrations.
• Always 404 on check → you are probably sending the automation ID, not the enrollmentId returned by the trigger. They are different values.
• Always denied → confirm you are passing the code as a string and not trimming a leading zero somewhere in your client.
• Trigger returns 201 but nothing is sent → the automation is probably still a draft. Publish it.
• Rate-limit responses → you are checking one handle too often; back off between attempts.

Related: Send your first OTP · Verification analytics · Use the API Reference

Overview. Solutions → Verification → Analytics shows the OTP funnel and outcomes across SMS, WhatsApp and Email, so you can see how many users actually get through your verification step — usually one of the highest-drop-off moments in any sign-up.

What you see

• Started — verifications begun in the range.
• Approved and Success — how many completed, and the rate. This is the number to watch.
• Expired — the code lapsed before the user entered it. High values mean your expiry is too short, or delivery is too slow.
• Locked — hit max attempts. A little is healthy; a lot suggests the code is hard to read or users are being sent the wrong one.
• In progress — started and not yet resolved, which is normal at the edge of the range.
• Average time to verify — how long users take. A rising figure usually means delivery latency, not user hesitation.
• By channel — the same funnel per channel, which is how you decide whether to move traffic to WhatsApp or add an SMS fallback.

How to read it

• Low success with high expired → a delivery problem. Check the channel's delivery log before touching the expiry setting.
• Low success with high locked → a usability problem. Shorten the code, or check whether your app is autofilling it incorrectly.
• One channel much worse than the others → move traffic. This is the single most actionable thing on the screen — Email typically trails SMS and WhatsApp, which is why fallback ordering matters.
• Success that drops suddenly → look at sender or template status first; an unapproved WhatsApp authentication template or a suspended sender ID shows up here before anywhere else.

Troubleshooting

• "No verifications in this range" → widen the range, or confirm your app is calling the trigger at all.
• Numbers look lower than your own logs → records are retained for about 90 days. Anything older has aged out.
• Started is far above Approved and nothing is expired or locked → users are abandoning without entering a code. That is a funnel problem in your app, not in Relay.

Related: Send your first OTP · Check a code from your app · Delivery receipts (DLRs) & message statuses

Overview. Alongside Relay's own AI Sales Agent, you can enable Meta Business Agent — Meta's AI agent — on one of your WhatsApp numbers, and configure all of it from Channels → WhatsApp → Business Agent. Meta runs the model and the conversation; Relay is the control panel.

Steps

1. 1. Accept Meta's terms. Meta requires first-time setup and its Business Agent Terms of Service to be accepted in WhatsApp Manager — this cannot be automated. Relay links you straight there and records the confirmation. You need to be an admin of that business portfolio; if the tab isn't there, you don't have the right role rather than the wrong link.
2. 2. Eligibility. Run the check to see whether Meta will allow the agent on this number. If it comes back not eligible, Relay tells you why — country, business vertical, or setup not yet completed in WhatsApp Manager. Saudi Arabia, the UAE, Egypt and the rest of the GCC are supported, and the number itself must already be Registered. Supported industries are Automotive, Consumer Goods, Professional Services, Retail & Ecommerce, and Travel.
3. 3. Webhook fields. Confirm the subscription Meta needs to route conversations. Your Meta app must be subscribed to standby and messaging_handovers as well as messages — without them Relay stops seeing replies on that number once the agent takes over. If the step doesn't go green, ask your Relay contact to confirm it.
4. 4. Create the agent. Pick the WhatsApp number and create it. The screen then shows which agent — Meta's or Relay's — currently answers each of your numbers.

Teach it about your business

• Business information — What the business does, Payment methods, Returns & refunds, purchase info, Delivery & shipping, Contact email and Opening hours. Fill these in first; they answer most questions on their own.
• FAQ — a library of question-and-answer pairs for the things customers actually ask.
• Websites — pages for Meta to crawl, with live crawl status and a pages-crawled count.
• Documents — PDF, Word, Excel, CSV and images, up to 100 MB.

Skills — where tone and language live

• Each skill has Instructions (how the agent should behave) and a When to use it description that "tells the agent which conversations this skill applies to".
• Be specific in When to use it. A vague description is why a skill never fires.

Behaviour and rollout

• Behaviour — the Handoff message ("what the customer sees as the agent hands over"), and an optional Follow-up message that "sends one nudge after the delay below".
• Allowlist — start on Only allowlisted numbers (recommended) and add your own numbers, then switch to Everyone who messages this number when you're happy. Relay's own advice: "Start with a small allowlist. You can open it up once you're happy with the answers."
• Try the agent — a free test console; Meta does not bill test messages. It shows the reply, any quick replies, and whether the agent would have handed off.

Troubleshooting

• "not eligible" → read the reason. Country and business vertical are Meta's decisions and cannot be appealed from Relay; "setup not completed" means go back to WhatsApp Manager.
• You can't find the terms tab in WhatsApp Manager → you are not an admin of that business portfolio. Get the role, then retry.
• "Relay's AI Sales Agent is active on this number" → only one agent can answer a number. Use Review the Relay agent and put it on standby in one click, or pick a different number.
• The agent answers in English when you wanted Arabic → that's a skill instruction, not a setting. Edit the tone-and-language skill.
• A skill never fires → its When to use it description is too vague. Make it concrete.

Related: Connectors & agent performance · Set up the AI Sales Agent · Handle the Conversations inbox

Overview. Documents and FAQs only let the agent answer things that were true when you wrote them. Connectors let it look things up in your own systems mid-conversation — order status, bookings, stock — so "where is my order?" gets a real answer. Performance then tells you what the agent handled and roughly what Meta charged.

Connectors

1. Open Connectors → New connector and describe What this connector can do.
2. Add an action with an Action name (lowercase letters, numbers and hyphens — e.g. order-status) and a When to use it description. "The agent reads this to decide when to call it — be specific."
3. Set the base URL (must be https) and the action path (relative to the base URL).
4. Choose Authentication — API key (with a Header name) or OAuth2 client credentials (client id and Client secret).
5. Map the inputs. Meta can pass the customer's WhatsApp phone number automatically, so shoppers never have to identify themselves.
6. Press Test — it calls your real backend, so you find out now rather than in front of a customer.

Watching connectors in production

• Recent calls (last 7 days) shows success rate and latency per action. Check it after go-live and after any change to your backend.
• Latency matters more than usual here: the customer is waiting in a chat. A slow connector reads as a broken agent.
• "No call data yet" means the agent has never decided to call it — almost always a When to use it description that's too vague, not a wiring problem.

Performance

• Pick the number and a period — 7, 30 or 90 days.
• Messages and conversations handled, and the share resolved without a human.
• Team takeovers — how often a person had to step in. Rising takeovers on one topic is a gap in the knowledge or a missing skill.
• Estimated Meta cost. Meta bills per token and publishes no usage API, so Relay can only estimate this. It is not an invoice figure — reconcile against Meta's own billing.

In the inbox

• Conversations the Meta agent handled are badged in Conversations.
• Take over pulls a conversation to a human; Return to agent hands it back.
• If Meta refuses the handover you will see a message saying Relay isn't registered as the escalation partner for that number. That has to be arranged with Meta — contact your Relay representative.
• A takeover is the right move whenever the customer is frustrated — the handoff message you configured under Behaviour is what they see.

Troubleshooting

• Test fails → check the URL is https and the path is relative to the base URL. Then check your backend accepts the auth header you named.
• The agent gives stale answers → it is answering from documents rather than calling the connector. Tighten When to use it.
• Estimated cost looks wrong → it is an estimate by design. Use Meta's billing for anything financial.
• You rotated a secret and calls fail → re-enter it here; Relay never stored the old one, so there is nothing to fall back to.
• Takeovers spiking → read the transcripts of the handed-off conversations. The fix is usually one FAQ entry or one skill.

Related: Set up the Meta Business Agent · Handle Cases (human hand-off) · Agent Performance

Overview. Relay is passwordless — you sign in with your work email and a short code sent to your inbox. Nothing to remember, nothing to leak.

Steps

1. Enter your work email at your Relay URL.
2. Enter the 6-digit code from your inbox (expires ~10 min; use Resend if it lapses).
3. New here? Choose Sign up and verify the same way. Use a company email — public domains (gmail, outlook…) are blocked.
4. If your org uses SSO, use the SSO / “Advanced options” path and sign in with your identity provider.

Best practices

• Add @your-relay-domain to your email safe-senders so codes don't land in spam.
• Turn on 2FA right after your first sign-in.

Troubleshooting

• No code arrives → check spam, wait a moment, then Resend; confirm you used the same email your account is on.
• “Code expired” → request a new one (codes are short-lived by design).
• Sign-up blocked → you likely used a public-domain email; use your company address.

Related: Set up 2FA · Accept a team invitation

Overview. 2FA adds a second factor (a rotating code from an authenticator app) on top of your email sign-in — strongly recommended for anyone who can send messages or see customer data.

Steps

1. Use the MFA setup gate after first sign-in, or open Settings → Security.
2. Scan the QR code (or copy the manual key) into your authenticator app.
3. Enter the 6-digit code to confirm. You may “skip for 7 days” unless your org enforces it.

Best practices

• Admins: enforce 2FA org-wide in Settings → Security so every member is protected.
• Save your authenticator's backup/recovery codes somewhere safe.

Troubleshooting

• “Invalid code” → your phone's clock is likely out of sync; enable automatic time on the device.
• Lost your device → an admin can reset your MFA from Team Management.

Overview. When a colleague invites you, you activate your account from the invitation email and land in the portal with the role they assigned.

Steps

1. Click the link in your invitation email (opens the Accept invite screen).
2. Confirm your name and sign in with your email + one-time code (or SSO).
3. You'll get your assigned role — Admin / Editor / Viewer / Agent.

Troubleshooting

• “Invite expired” → ask an admin to resend it from Settings → Team Management.
• Wrong permissions → your role controls access; an admin can change it.

Related: Team management (invite & roles)

Overview. The guided wizard (“Sell on WhatsApp in an afternoon”) stitches the three setup tasks into one place so you reach a live, sending journey quickly. Do the steps in any order — progress is saved.

Steps

1. Connect WhatsApp → opens WhatsApp Accounts (flips to “Manage WhatsApp” once a number is Registered).
2. Connect a store → Integrations (Salla / Shopify / WooCommerce / Zid; dev-sandbox available).
3. Choose a kit → Automation Gallery to instantiate a journey.

Best practices

• Do all three — a store connection makes your automations commerce-aware and your AI agent catalogue-grounded.
• Start with the abandoned-cart or welcome kit for the fastest ROI.

Related: Connect a WhatsApp number · Connect your store · Use a starter kit

Overview. The left sidebar groups everything by job. Here's the map — and the Dashboard, which is where you land:

• Dashboard — live throughput, delivery rate, recent campaigns.
• Contacts / Segments / Tags / CDP Hub — audience & data.
• Campaigns (broadcasts) · Automations (journeys).
• Engage → Cases / Performance — the human handoff workspace.
• Channels → SMS / WhatsApp / Email — templates, testing and a delivery Explorer for each.
• Solutions → eCommerce (Get Started, Stores, Dashboard, AI Sales Agent) / Verification (OTP).
• Developer Tools — API & Integrations, Apps, API Reference, Webhooks.
• Settings and Billing, from the avatar menu top-right.

What you see depends on your plan and what's enabled for your account. Agents see a focused view (Cases + My Performance).

Overview. Upload a CSV to create or update contacts in bulk. The wizard maps your columns, previews the data, and flags duplicates before anything is saved.

Before you start: a .csv with at least a Phone column (E.164, e.g. +9665…). Optional: name, email, Opt-In, tags, attributes. Up to 50 MB / 100k+ rows.

Steps

1. Contacts → Import opens the wizard (Upload → Preview → Result).
2. Drop the file; review the CSV Column Guide, mapping, and duplicates.
3. Confirm; review imported vs skipped.

Best practices

• Include and map the Opt-In column — consent governs who you can legally message.
• Only import contacts who gave you consent; never a purchased list (it wrecks deliverability).
• Add tags/attributes on import so you can segment immediately.

Troubleshooting

• Rows skipped → usually a missing/invalid phone; fix formatting to E.164 and re-upload.
• Numbers look wrong → check the country/calling code; the preview shows the parsed value.

Related: Create a segment · Deliverability & compliance (Knowledge Base)

Overview. The contact profile is your single source of truth for a person — identity, consent, engagement, and commerce history pulled from connected stores.

Steps

1. Click any row in Contacts.
2. See identity, opt-in status, tags, and engagement score.
3. Review the eCommerce summary — LTV, orders, AOV, last purchase, RFM segment, preferred payment methods.
4. Edit or delete (delete confirms).

Best practices

• Use the RFM segment and LTV here to decide how much to invest in a customer (VIP vs win-back).

Related: Building high-value segments with RFM (Knowledge Base)

Overview. Filter your contacts, then save that filter as a segment — a named, reusable audience that updates itself as contacts change.

Steps

1. Filter Contacts — the query bar (e.g. rfmSegment = At Risk, totalOrders >= 3), or the Subscribed / Opt-in pills.
2. Click Save as Segment.
3. Review the Definition preview and ~N contacts, name it, then Create Segment.

Best practices

• Combine RFM with commerce attributes (category, COD-risk) for sharp audiences.
• Keep names action-oriented (“VIP – fashion”, “At-risk – 60d”).

Segments saved this way are live (dynamic) — membership updates automatically, and they work in both Campaigns and Automation triggers.

Related: Building high-value segments with RFM (Knowledge Base)

Overview. The Segments screen lists every audience you've saved. Segments are created from Contacts, then reused across Campaigns and Automations.

Steps

1. Open Segments; search “Search segments…”.
2. Check Type (live / static) and Contacts count; dynamic ones show their rule.
3. Click a segment to open Contacts filtered to it.

Troubleshooting

• “No segments yet” → create one from the Contacts page (Save as Segment).
• Count looks off → dynamic segments recompute; the count reflects current membership.

Overview. Tags are lightweight labels on contacts (e.g. vip, wholesale). The Tags screen shows each tag's reach so you can spot useful audiences.

Steps

1. Open Tags; search “Search tags…”.
2. Review each tag's Reach bar and Contacts count.
3. Click a tag to open Contacts filtered to it.

Best practices

• Apply tags in automations (Add tag) to mark milestones like new-customer or vip, then segment on them.

Overview. The CDP Hub shows the structured attributes Relay has enriched onto your contacts (from messages and connected stores) and suggests segments worth targeting.

Steps

1. Open CDP Hub.
2. Review enrichment KPIs and the attribute distribution/breakdown.
3. Read the AI advisory items (impact High/Medium/Low) for segment and campaign ideas.

Best practices

• Act on the highest-impact advisory first, then build a segment for it in Contacts.

Overview. When the same person arrives from multiple sources, Relay stitches them together. High-confidence matches merge automatically; ambiguous ones wait for your decision here.

Steps

1. Open Integrations → Merge Review.
2. Compare candidates side-by-side; read the match rationale + confidence.
3. Choose the primary record and Merge, or Keep separate.

Best practices

• Clear the queue regularly — duplicates split a customer's history and mis-score RFM.

Decisions are audited (who + when). Only ambiguous matches appear here.

Overview. Campaigns are one-time broadcasts. The builder walks you through five steps and shows live cost/parts so there are no surprises.

Steps

1. Campaigns → New Campaign (Setup → Audience → Content → Schedule → Review).
2. Setup: channel SMS, name, Sender ID.
3. Audience: select segments and/or upload a CSV; set the Mobile Number Column; check Estimated Reach.
4. Content: write the body (live parts counter); Suggest for AI copy; optional CTA link.
5. Schedule → Review → Confirm Launch.

Best practices

• Keep it to one part where possible — Arabic (UCS-2) is 70 chars/part, so write tight.
• Personalise with a variable (first name / last product) — it lifts response.
• Send to a segment, not everyone; relevance beats reach.

Troubleshooting

• Sent later than expected → quiet hours deferred a promotional send to the next open window (by design).
• Sender ID not selectable → it isn't approved for your account yet (see Sender IDs).

Related: A/B test with holdout · Read campaign performance

Overview. WhatsApp broadcasts use pre-approved templates. You map each template variable to a contact attribute or CSV column.

Steps

1. New Campaign → Setup: channel WhatsApp, pick your WhatsApp Number.
2. Audience: segments / list.
3. Content: Select WhatsApp Template, choose Locale, complete Variable Mapping.
4. Schedule → Review → Confirm Launch.

Best practices

• Add an SMS fallback so WhatsApp-unreachable contacts still get the message once.
• Match the template category to intent (marketing vs utility) to avoid throttling.

Troubleshooting

• No templates to pick → you need an Approved template first (WhatsApp → Templates).
• Variables blank → check the mapping; unmapped variables fall back to their sample/default.

Overview. A/B testing compares message variants; a holdout (a group that gets nothing) lets you measure the true incremental lift, not just which variant looked better.

Steps

1. In the SMS Compose step, add named variants with a % split.
2. Optionally set a holdout / control (up to 30%) that receives nothing.
3. Launch; compare per-variant results and promote a winner to the remaining audience.

Best practices

• Test one thing at a time (offer or copy), and keep the holdout for high-value sends.
• Let it run long enough to reach a meaningful sample before declaring a winner.

A/B testing is available for SMS campaigns today.

Related: Measuring what matters (Knowledge Base)

Overview. Send immediately or schedule for a future date/time/timezone. Promotional sends automatically respect quiet hours.

Steps

1. In Schedule, choose Immediate or Scheduled (date/time/timezone, ~40 zones).
2. Edit a scheduled campaign in its window and Save Changes.

Promotional sends respect your account's quiet hours — a message outside the window is deferred to the next open window, never dropped. Transactional/OTP is exempt.

Overview. The performance view shows delivery and engagement for a campaign, including per-variant results for A/B sends.

Steps

1. Open a campaign and choose View.
2. Review Sent · Delivered · Failed · Opt-outs · Read · Clicks · Conversions.
3. For A/B, see the per-variant breakdown.

Best practices

• Watch opt-outs and failed/blocked — a spike signals wrong audience or a deliverability issue.
• Tie revenue back via the eCommerce dashboard's attributed revenue.

Overview. Automations are journeys that enroll contacts on a trigger and run steps automatically. This is where lifecycle revenue compounds — build cart recovery, welcome series, win-backs, and more.

Steps

1. Automations → New Automation: Name, Category, Create Draft.
2. Click the entry node → Pick a trigger.
3. Add a step from the palette; configure it in the side panel.
4. Save Draft, then Publish.

Best practices

• Start from the Gallery — a proven flow beats a blank canvas.
• Add an entry condition (e.g. don't enroll people who already bought).
• Set a frequency cap so overlapping journeys don't over-message a contact.

Troubleshooting

• Publish is blocked → the linter found an error (empty branch, orphaned step); fix the highlighted node.
• No one is enrolling → check the trigger and entry condition, and that the automation is Published (not draft).

Related: Cross-vertical playbooks (Knowledge Base) · Use a starter kit

Overview. The Gallery has ready-made automations you can instantiate and customise — the fastest way to launch a best-practice journey.

Steps

1. From Automations, click Gallery.
2. Browse cards by Engagement / Commerce / Transactional / Lifecycle (each shows “{n} min setup”).
3. Click Use this — a customisable draft opens in the builder.

Best practices

• Some kits need a store integration — connect your store first so triggers like cart.abandoned work.

Overview. An automation starts on one trigger and runs a sequence of actions. Here's the full palette.

Triggers (34)

Time (schedule, recurring, N-days-before/after, birthday, Hijri-calendar date) · contact lifecycle (created, tag/segment/attribute changes, opt-in/out) · outbound events (delivered, failed, read, email opened, link clicked, conversion) · WhatsApp inbound · webhook/API · manual · eCommerce (order created/paid/fulfilled/delivered/cancelled/refunded, cart/checkout abandoned, wishlist) · browse pixel (product/category viewed).

Actions (33)

Sends (SMS, WhatsApp, email, opt-in request) · waits (delay, wait-for-event) · branching (if/else, switch, random split) · contact mutation (attribute, tag, segment, opt-in/out) · Handoff to human · HTTP webhook · call sub-automation / jump · 4 AI steps (generate, classify, sentiment, language) · goal tracking (mark conversion, increment counter) · generate OTP · eCommerce (catalogue, product carousel, generate coupon, flag VIP, suppression) · End.

WhatsApp send steps can carry an SMS fallback for unreachable contacts.

Overview. Relay gives you real safety rails so a live journey can't run away — versioning, an instant stop, and automatic protection against error storms.

Steps

1. Publish validates and goes live (errors block publishing).
2. Open Version history → roll back to a prior published version.
3. Use Pause/Resume, or the kill switch to instantly halt new and in-flight enrollments (reversible).

Best practices

• Test changes in a draft; publish during business hours so you can watch the first enrollments.
• Set per-automation compliance flags (quiet-hours, DND, opt-out-footer, transactional exemption) to match the journey's intent.

A circuit breaker auto-pauses an automation if its error rate spikes — check the error and re-publish once fixed.

Overview. Analytics show enrolments, completion, conversions, and where contacts drop off — so you know exactly which step to improve.

Steps

1. Open Analytics for an automation; pick 24h / 7d / 30d.
2. Review Enrolments, Completion rate, Conversions; read the funnel + recent enrolments.
3. Export CSV for the window.

Best practices

• Find the biggest drop-off step and fix one thing (timing, copy, or an over-long wait).

Overview. Templates are reusable message bodies with typed variables and multi-locale support, gated by an approval workflow so only vetted content goes live.

Steps

1. Channels → SMS → SMS Templates → New Template.
2. Set Name, Description, Category, Default Locale, allowed senders.
3. Write per-locale bodies (live parts/encoding counter) and declare variables with fallbacks.
4. Save, then Submit for Review; track Draft → Pending → Approved / Rejected.

Best practices

• Give every variable a fallback so a missing value never prints “{token}”.
• Write the Arabic locale tightly — UCS-2 is 70 chars/part.

Troubleshooting

• Rejected → read the reason, fix, and Resubmit for Review.
• Can't edit body → approved templates lock body/schema; clone or edit metadata only.

Overview. Send yourself a single SMS to check rendering, parts, and delivery before you broadcast to real customers.

Steps

1. Channels → SMS → SMS Testing.
2. In Single Message Test, set the Recipient (locked to your verified number on the free plan) + Sender ID.
3. Use Live Preview to check parts/encoding; send; review Test History and open Message Detail.

Best practices

• Always test Arabic content — encoding flips to UCS-2 and changes the part count and cost.

Overview. The Messages Explorer is your delivery audit trail — search every message, inspect its status, and export for reporting.

Steps

1. Channels → SMS → Explorer (defaults to today).
2. Filter by Search (sender, destination, message ID, text) + From/To dates (≤90-day range) + status.
3. Open a row for Message Detail; Export to CSV.

Troubleshooting

• Status “Blocked” → a content-filter or DND rule stopped it; the detail view shows the reason.
• Status “Failed” → open the detail for the carrier error code (bad number, unreachable, etc.).

Overview. A Sender ID is the brand name recipients see. You can only send under IDs approved for your account — this prevents impersonation.

Steps

1. Settings → SMS Senders: submit a brand name (≤11 chars) + use-case description.
2. Track status (Approved / Pending / Rejected, with reason).
3. Approved senders show as Active in the same list and become selectable in the campaign builder.

Troubleshooting

• Rejected → the reason is shown (e.g. name too generic / not matching your brand); adjust and resubmit.
• Free tier → sends use the shared Sandbox sender until you register your own.

Overview. Connect your WhatsApp Business Account (WABA) via Meta's Embedded Signup so Relay can send and receive. Relay shares its business credit line with your WABA, so you don't need to set up Meta billing yourself.

Steps

1. Channels → WhatsApp → Accounts; start Embedded Signup and authorise.
2. Expand the WABA to see numbers with state badges (Pending → Verified → Registered).
3. Use per-number panels to register, edit profile/name, or set the PIN (two-step verification).

Best practices

• Watch the quality rating — keep it green by only messaging opted-in contacts and avoiding high opt-out sends.

Troubleshooting

• Can't send yet → the number must reach Registered first.
• Credit line failed → use the “Attach credit line” retry, or contact your Relay admin.

Overview. WhatsApp requires pre-approved templates to start conversations. Relay lints against Meta's policy before you submit, so more templates pass first time.

Steps

1. Channels → WhatsApp → Templates: Sync all from Meta to import existing ones, or New Template.
2. Set category (Marketing / Utility / Authentication), locales, components, and {{n}} variables with samples.
3. Submit to Meta; track per-locale status; use Sync status to refresh.

Best practices

• Choose the right category — mis-categorised marketing-as-utility templates get rejected or throttled.
• Marketing templates on an enrolled number route via MM Lite for better delivery at the same price.

Troubleshooting

• Rejected by Meta → the status shows why; fix policy issues (promotional content in a utility template is common) and resubmit.

Overview. A two-pane inbox for live WhatsApp conversations, with the 24-hour service-window timer front and centre so you know when a free-form reply is allowed.

Steps

1. Channels → WhatsApp → Conversations.
2. Browse threads (last message, unread count, opt-in, 24h service-window timer).
3. Reply within the window; click Return to AI to hand a thread back to the agent.

Troubleshooting

• Can't send a free-form reply → the 24h window has closed; send an approved template instead, or wait for the customer to message again.

Overview. The WhatsApp Explorer mirrors the SMS one for WhatsApp — search, inspect the full status timeline, and export.

Steps

1. Channels → WhatsApp → Explorer.
2. Filter by direction, status, message type, number, and date (≤90 days).
3. Open a row for the status timeline (every transition + error codes) and raw payload; Export CSV.

Overview. The AI Sales Agent answers WhatsApp questions from your catalogue and knowledge base, recommends products, and escalates to a human when it should. Results come from a good knowledge base and tight guardrails — not the model.

Steps

1. eCommerce → AI Sales Agent; select or create an agent.
2. Set Model, greeting, language (auto/Arabic/English), and the WhatsApp number.
3. Fill the Knowledge Base sections; set guardrails (grounded-only, discount ceiling, off-limits topics) and handoff rules.
4. Create agent / Save, then set status active.

Best practices

• Start grounded-only with a full knowledge base; reindex after big edits.
• Connect your store so the agent references real products, stock, and orders.
• Review Cases weekly — each hand-off is a KB gap to fill (and containment climbs).

Troubleshooting

• Agent hands everything off → the knowledge base is too thin; add the top questions.
• Gives away too much discount → set/lower the discount ceiling.

Related: The WhatsApp AI Sales Agent playbook (Knowledge Base) · Handle Cases

Overview. When the agent (or an automation) escalates, a Case opens for a human. The workspace gives you the AI summary, the live thread, and dual-mode replies so you can resolve fast.

Steps

1. Support → Cases; filter by Status / “mine”.
2. Open a case: read the AI summary, the live thread, and the contact rail (RFM, LTV, orders).
3. Reply Via AI (the agent rephrases your draft) or Directly; assign, add notes, Return to AI, or Close.

Best practices

• Answer within the SLA (default ~60 min); use “Via AI” to keep a consistent voice.
• Note the handoff reason — it tells you what to add to the agent's knowledge base.

Overview. Leaderboards for both your human team and your AI agents, so you can see resolution speed, SLA health, and how much the AI is handling on its own.

Steps

1. Support → Performance; pick 7d / 30d / 90d.
2. Human Agents: handled/resolved, first-response & resolution times, SLA breaches.
3. AI Agents: conversations, containment rate, handoffs, avg turns/confidence, sentiment.

Best practices

• Track containment over time — rising containment means your KB is improving.
• Use the top handoff reason as your next KB fix.

Overview. Connecting your store is the unlock for everything commerce — order/cart/browse signals power segments, automation triggers, and revenue attribution.

Steps

1. Integrations → click Connect on your platform's card.
2. In “Connect {Platform}”, enter the store identifier — Salla domain/ID; Shopify *.myshopify.com; Zid OAuth; WooCommerce site URL + Consumer key/secret.
3. Authorise/verify; the connection goes live and historical backfill begins.

Best practices

• Connect before building commerce automations so triggers like cart.abandoned have data.
• Add the browse/cart pixel to power abandoned-browse journeys.

Just exploring? Use a dev-sandbox store (tagged “Dev stub”) to see the flow before wiring real credentials.

Overview. Each connection card shows health (events received, failures, last event) and lets you pause, refresh, or disconnect.

Steps

1. On Integrations, click a connection card (Events 24h / Failed 24h / Last).
2. Pause / resume / disconnect, trigger a manual refresh, and review authorised scopes + the last error.

Troubleshooting

• “Needs attention” / errors → open the connection, read the last error, and reconnect if the store revoked access.

Overview. The eCommerce dashboard connects your messaging to money — attributed revenue, cart recovery, VAT, and your RFM lifecycle distribution in one place.

Steps

1. eCommerce → Dashboard; pick 7d / 30d / 90d.
2. Review revenue & attributed revenue, orders trend, VAT split, top SKUs, cart recovery.
3. See the RFM distribution (11 segments); click to recompute.

Best practices

• Watch the RFM distribution monthly — more Champions over time means your lifecycle programme is working.

Related: Measuring what matters (Knowledge Base)

Overview. Generate a hosted payment link inside a conversation and track it to paid — useful for closing a sale in chat or requiring prepayment from COD-risk customers.

Steps

1. Generate a hosted payment link from an agent chat, automation step, or inbox reply.
2. Track its lifecycle (pending → paid / expired / cancelled); a paid link is credited as revenue attribution.

Payment-link support is available and maturing; native WhatsApp Pay is on the roadmap.

Overview. Apps are containers that isolate traffic, rate limits, and credentials — create one per integration or environment (e.g. production vs staging).

Steps

1. Developer → Apps → New App; set TPS cap, daily/monthly limits, default flag.
2. Open the app to view usage and bind credentials.
3. Generate a REST key (sk_live_…, shown once — copy it) and/or an SMPP binding; add an IP allowlist (single IPs or CIDR).

Best practices

• Use separate apps/keys per environment so you can revoke one without affecting others.
• Set an IP allowlist for production credentials.

Troubleshooting

• 401 / auth errors → the key is wrong, deactivated, or the caller IP isn't allowlisted.
• Messages not routing → the app may be paused (paused apps block routing).

Overview. An interactive, in-portal API reference — read the contract and call endpoints live with your own key.

Steps

1. Developer → API Reference.
2. Browse grouped endpoints (Contacts, Segments, Campaigns, Messages incl. bulk ≤1000/request, WhatsApp, Apps, Billing).
3. Use Try It with your key. SMS is also available over SMPP 3.4 (System ID + password).

Best practices

• Batch with the bulk endpoint (≤1000 recipients/request) rather than looping single sends.

Overview. Receive delivery receipts at your endpoint, and monitor every outbound webhook delivery with retries, a dead-letter queue, and manual replay.

Steps

1. Set a DLR webhook URL in credentials to receive delivery receipts.
2. Developer → Webhooks: see status (pending / success / failed / DLQ / replayed), attempts, and last response code.
3. Open a delivery for the full request/response and per-attempt audit; Replay failed/DLQ items.

Best practices

• Verify the HMAC signature (SHA-256/512) on inbound webhook endpoints before trusting a payload.
• Return a 2xx quickly; do heavy work async so deliveries aren't retried needlessly.

Overview. See your plan and usage against included allowances (contacts, seats, AI conversations, WhatsApp numbers), change plan, and manage payment.

Steps

1. Open Billing; review your plan and usage vs allowances.
2. In the catalog, click Select {Plan} or Upgrade Plan and complete checkout.
3. Manage Payment Method and view Invoice History.

Best practices

• Watch quota banners across the app — they deep-link here before you hit a hard limit.

Relay supports subscription, prepaid-wallet, and postpaid billing. For pricing, contact your Relay account team.

Overview. Your org's identity and the Account ID support will ask for.

Steps

1. Settings → Organization.
2. Set org name, logo, website, and primary industry; copy your Account ID when contacting support.

Overview. Invite teammates and give each the least access they need. Roles: Admin (full), Editor (campaigns/contacts/settings), Viewer (read-only), Agent (Cases + performance only).

Steps

1. Settings → Team Management; invite with name + email.
2. Choose a role (Admin / Editor / Viewer / Agent).
3. Resend, suspend, or remove members (admin only).

Best practices

• Give support staff the Agent role — they get a focused Cases view and can't change settings.

Overview. Org-wide security controls — enforce 2FA, connect SSO, and restrict access by IP.

Steps

1. Settings → Security.
2. Enable and optionally enforce 2FA (TOTP) org-wide.
3. Enable and optionally enforce SSO (OIDC / SAML).
4. Configure the IP allowlist (REST + SMPP) and session timeout.

Best practices

• Enforce 2FA (or SSO) org-wide for anyone who can send messages or view customer data.

Overview. Choose which platform events notify you and where (email / in-app).

Steps

1. Settings → Notifications.
2. Toggle email / in-app channels and set the per-type matrix (campaign completed, invoice issued, security alert…).

Overview. Relay keeps your promotional sends within regulator-aligned hours automatically, so you stay compliant without thinking about it.

• Per-country, per-channel quiet hours in the recipient's local time — promotional sends are deferred, not dropped; transactional/OTP is exempt.
• Legal windows for KSA, UAE, Qatar; recommended elsewhere; a Ramadan mode shifts them automatically.
• A DND registry suppresses do-not-disturb numbers automatically.

What you control: frequency caps — how many messages one contact may receive per day and per week — are yours to set in Settings. What your operator controls: the per-country legal quiet-hour windows and the DND registry, which are regulator-aligned and not per-account. Contact them only for those.

Related: Deliverability & compliance in MENA (Knowledge Base)

Lifecycle marketing means matching the message to where a customer is in their journey — and letting automations do it for you. That's where the compounding revenue is.

The five stages & the Relay tool for each:

• Acquire — get consent → opt-in request step, contact import.
• Onboard — first value/first purchase → welcome series, AI Sales Agent.
• Grow — repeat & higher AOV → post-purchase series, recommendations, segment campaigns.
• Retain — keep them loyal → reorder reminders, VIP treatment, RFM journeys.
• Win back — recover lapsing buyers → win-back ladder, at-risk RFM segments.

The flywheel: signals in (orders/carts/browse) → segments update themselves → automations fire on triggers → revenue is attributed → you double down on what works.

Where to start (first 30 days), by ROI:

1. Abandoned-cart recovery (fastest money).
2. Welcome / first-purchase series.
3. Post-purchase order & shipping updates.
4. Win-back for lapsed buyers.
5. The AI Sales Agent to handle the conversations these create.

Next: Cross-Vertical Playbooks

SMS — reach & reliability. Works on any phone, no app. Best for OTP/transactional alerts and broad reach. 160 chars/part (70 for Arabic) — Relay counts parts live.

WhatsApp — conversation & commerce. Media, buttons, catalogues, real replies. Two modes: template messages (Meta-approved, needed to start a conversation) and session messages (free-form, only inside the 24-hour customer-care window).

How to decide:

• OTP / login code → SMS.
• You have WhatsApp opt-in and want engagement → WhatsApp.
• Broad promo, unknown reachability → SMS, or WhatsApp with an SMS fallback.
• Two-way support / product Q&A → WhatsApp + AI agent.
• Recipient outside the 24h window → a template, not free-form.

Best practice: set a WhatsApp→SMS fallback so unreachable contacts still get the message once — never double-send.

RFM scores every contact on Recency, Frequency, and Monetary value from order history. Relay computes it nightly (tenant-relative quintiles) and buckets contacts into 11 lifecycle segments you can target directly; recompute on demand from the eCommerce dashboard.

The plays:

• Champions / Loyal — status & early access, not discounts (they'll buy anyway).
• Potential Loyalists / New / Promising — onboarding & education to build the habit.
• Need Attention / About to Sleep — re-engage before they lapse.
• At Risk / Can't Lose Them — win-back scaled to value (high-touch for high value).
• Hibernating / Lost — last-chance incentive, then suppress.

Use it: build segments in Contacts → Save as Segment (e.g. rfmSegment = At Risk + category + COD-risk), feed them into campaigns and automations. Segments are live, so contacts move between journeys automatically as behaviour changes.

Deliverability is consent, timing, content, and channel health — not luck.

1. Consent first. Message only opted-in contacts; track opt-in status & source; use double opt-in where required; honour opt-outs (Relay maintains suppression + a DND registry).
2. Quiet hours. Relay enforces per-country, per-channel windows in the recipient's local time — promotional sends are deferred, not dropped; transactional/OTP is exempt. Legal windows for KSA, UAE, Qatar; a Ramadan mode shifts them automatically.
3. Sender health. SMS: send only under an approved Sender ID (anti-impersonation enforced). WhatsApp: keep your number's quality rating green and mind your messaging tier.
4. Content that lands. Keep SMS tight (Arabic costs more per part); get WhatsApp templates approved under the right category; avoid spammy patterns.

Common mistake: importing a purchased (non-consented) list — it wrecks deliverability and breaks the rules.

Baseline every metric first, then set a target. The KPIs that matter, by objective:

• Delivery: delivery rate, failed/blocked (Message Explorer) — a drop signals a deliverability/sender problem.
• Engagement: WhatsApp read rate, clicks, replies.
• Revenue: conversions & attributed revenue (eCommerce dashboard) — the number that matters most.
• Automation health: completion & per-step drop-off (funnel), error rate.
• Commerce: cart-recovery rate, new-vs-returning, AOV, RFM shift over time.
• Conversational: AI containment rate, first-response SLA, sentiment.

Attribution links touches (sent/delivered/clicked, by A/B variant) to orders (last-touch), plus in_chat_payment for payment links.

Always be testing: use A/B with a holdout on SMS to measure true incremental lift, then promote winners.

A great agent answers 60–80% of questions itself (high containment), never invents products/prices, and hands off cleanly when it should.

Set it up for success:

1. Feed it a real knowledge base — fill every section (shipping, returns, checkout, pricing, smart selling, FAQs, about). Reindex after big edits.
2. Keep it grounded-only; set a discount ceiling and off-limits topics.
3. Connect your store so it references real products, stock, and orders.
4. Tune handoff — keywords, negative sentiment, low confidence, high order value; plus return-from-handoff.

Best practices: start narrow and loosen once you trust it; review Cases weekly — every hand-off is a gap in the KB (fill it and containment climbs); localise (auto language); watch Agent Performance (the top handoff reason is your next KB fix).

Common mistake: an empty knowledge base → the agent hands everything off and your team drowns.

The opportunity. Fashion is visual, seasonal, and identity-driven: high browse-to-cart drop-off (recovery is your biggest lever), seasonal drops & sales (incl. Ramadan/Eid), and style-led repeat purchase — people come back for the next look, not to reorder. WhatsApp fits perfectly: show the product, answer "will it fit?", close the sale.

Segments to build: VIP/Champions (early access), category affinity (targeted new-arrival campaigns), browsed-not-bought (from the pixel), seasonal at-risk, COD-risk.

Priority automations: (1) abandoned cart — lead with the item's image, skip the coupon for Champions; (2) welcome/first-purchase with a styling + fit/care tip; (3) new-drop announcement to Champions first, then affinity segments; (4) win-back triggered on new drops in a browsed category or a seasonal window — not a fixed timer (fashion isn't consumable).

MENA: use the Hijri trigger for Ramadan (modest/eveningwear, gifting) and Eid (new-outfit demand peaks); localise to Arabic.

AI agent KB: sizing & fit (the #1 question), returns/exchanges (high return rates — be clear), "style it with…" cross-sell, current drops.

Sample: "Still thinking it over, {{first_name}}? Your {{product_name}} is waiting — sizes are selling fast. {{cart_link}}"

KPIs: cart-recovery rate · new-drop revenue (Champions vs rest) · return rate · cross-season repeat rate.

Related: Cross-Vertical Playbooks · Foundations

The opportunity. F&B is bought weekly (or more), so small nudges compound fast and WhatsApp is already the ordering channel in MENA. Two dynamics dominate: habit & recency (win the next order this week — reorder reminders are the core play) and timing (breakfast/lunch/dinner are different audiences).

Online + offline: unify store (e.g. Salla) + POS (Foodics) into one contact view so a regular is a regular whether they order online or walk in. (Confirm POS connectors enabled for your account.)

Segments: frequent diners, lapsed regulars (act fast — a 2-week gap is meaningful), time-of-day, COD-risk.

Priority automations: (1) reorder reminder on the customer's own cadence — the money-maker; (2) order & delivery confirmation on WhatsApp; (3) welcome/first-order; (4) abandoned cart with a short fuse (~15–30 min — F&B carts expire fast); (5) early win-back.

MENA: Ramadan is the biggest F&B moment — use the Hijri trigger for Suhoor/Iftar timing and Eid; pre-Iftar reminders convert strongly.

AI agent KB: menu & availability, cut-off times, delivery zones/ETAs, allergens/halal, combos.

Sample: "Your usual {{item}}, {{first_name}}? Tap to reorder — ready in {{time}} ⏱️ {{link}}"

KPIs: order frequency · reorder-reminder conversion · lapsed-regular reactivation speed · Ramadan revenue vs baseline.

The opportunity. Two traits make lifecycle automation unusually powerful: replenishment (consumables run out on a predictable cycle — reminding just before run-out is the single highest-ROI automation) and advice-led buying (routines, shade/skin match, ingredients — a knowledgeable agent lifts conversion). Together: predict the reorder, and be the expert in the chat.

Segments: replenishment-due (days-since-last-order approaching run-out, per SKU), VIP, routine builders (bought one step, missing complements), lapsed.

Priority automations: (1) replenishment reminder timed just before run-out — the money-maker; (2) welcome + how-to-use + routine completion; (3) order/shipping + usage tip; (4) educational cart nudge; (5) win-back for missed replenishment.

MENA: Ramadan/Eid drive gifting & self-care — use the Hijri trigger for gift sets and limited editions; localise to Arabic.

AI agent KB: routines & how to layer, shade/skin-type matching, ingredients/suitability, hygiene returns.

Sample: "Running low on {{product_name}}, {{first_name}}? Reorder now so you don't skip a day of your routine ✨ {{link}}"

KPIs: replenishment-reminder conversion (headline) · repeat-purchase rate · routine-completion rate · AI containment on advice.

The patterns adapt to any repeat-purchase vertical — commerce segments, the priority automations, a grounded agent, and the cross-vertical playbooks. Only cadence and the agent knowledge base change:

• Electronics: long cadence between big-ticket items → monetise accessories & warranties post-purchase; agent KB = specs/compatibility/warranty.
• Home & Living: occasional, project-based → nurture with inspiration + seasonal refresh; agent KB = dimensions/materials/assembly.
• Grocery & Essentials: weekly — reorder-the-basket is the core value; agent KB = availability/substitutions/slots.
• Kids & Baby: age-stage driven → next-size/next-stage recommendations + replenishment (diapers/formula); agent KB = sizing/age/safety.

How to start any vertical: connect your store → build 3–4 commerce segments → instantiate the priority automations and tune the cadence → fill the agent KB with your top questions → layer the cross-vertical playbooks.

Why. The shopper showed high intent and you already have their contact. On WhatsApp it's conversational — they can reply and (you or the AI agent) close the sale.

Trigger: cart.abandoned (connected store; browse/cart pixel improves coverage) with an entry condition so you don't nag someone who bought.

The flow — a 3-touch ladder (more feels like harassment):

1. +1h helpful reminder with the cart items (SMS fallback) — no discount yet.
2. Branch: order.paid? → End (Mark conversion). Else +24h nudge + optional coupon.
3. +48–72h final "your cart is about to expire".

Message: "Hi {{first_name}} 👋 you left {{product_name}} in your cart. Want to finish up? {{cart_link}}"

Best practice: skip the coupon for Champions; lead with it for At-Risk. Quiet hours & frequency caps apply automatically.

Mistakes: discounting on the first touch (trains people to abandon on purpose); >3 messages; no entry condition.

Measure: cart-recovery rate & attributed revenue; per-step drop-off.

Trigger: order.paid; branch on first-order so first-timers get the full series and repeat buyers a lighter one.

Flow: thank-you + what's next → shipping updates (order.fulfilled/delivered) → post-delivery check-in (offer help / route to AI agent) → complementary recommendation or reorder nudge → tag new-customer, add to an onboarding segment.

Messages: "Thanks for your order, {{first_name}}! 🎉 We're preparing {{product_name}} now." … "People who bought {{product_name}} love {{complement}} — here's a little something to try it."

Compliance: order/shipping updates are transactional (exempt from quiet hours); the recommendation is promotional (quiet hours apply). Classify intent correctly so updates always go out immediately.

Measure: repeat-purchase rate, time-to-second-order, attributed revenue from the nudge.

Trigger: order.created where payment = COD.

Flow: WhatsApp "Confirm your order?" (Yes/No buttons) → wait-for-event → on "Yes" proceed; on "No" flag/cancel; on timeout, remind then flag → feed the outcome into a COD-risk segment.

Message: "Hi {{first_name}}, please confirm your COD order of {{order_total}} for delivery to {{city}}. Reply Yes to confirm or No to cancel."

Best practice: for repeat COD-failers, require prepayment via a payment link. Confirmation is transactional (exempt); use a template outside the 24h window.

Mistakes: no timeout branch; not using the outcome to build the COD-risk segment (you keep eating the same failures).

Measure: COD failure/return rate before vs after; confirmation reply rate.

Trigger: order.delivered + a 2–3 day wait (let them use the product).

Flow: optional AI sentiment check → branch: likely happy → review request link; likely unhappy → Handoff to human to fix it privately.

Message: "Hi {{first_name}}, how are you enjoying {{product_name}}? A quick rating helps others shop with confidence: {{review_link}}"

Best practice: ask once, make it one tap. Mistake: asking before delivery or after a delivery problem.

Measure: review reply/click rate; downstream conversion lift on reviewed products.

Trigger: segment entered — RFM At Risk, Can't Lose Them, or Hibernating (or days-since-last-order > N).

Flow: "we miss you" + a reason to return (new arrivals) → wait 3–5 days → branch (paid? → End) → stronger incentive (respect the discount ceiling) → last-chance → End.

Scale to value: Can't-Lose-Them → personal/VIP touch, a real reason (not just a coupon). At-Risk → modest incentive + what's new. Hibernating/Lost → biggest incentive or a low-cost final attempt, then suppress.

Mistakes: same offer regardless of past value; never suppressing truly-lost contacts.

Measure: reactivation rate by segment, revenue per win-back, RFM movement (At Risk → Loyal).

Trigger: time.birthday, or a Hijri-calendar date (Ramadan start, Eid Al-Fitr/Adha, or any Hijri month+day).

Flow: personalised greeting referencing their favourite category/last purchase → optional time-boxed offer → Mark conversion on redemption.

Messages: "Happy birthday, {{first_name}}! 🎁 {{coupon}} on your favourites ({{top_category}})." · "رمضان كريم، {{first_name}} — an early look at our Ramadan collection, just for you."

Best practice: time Ramadan/Eid sends with the eCommerce dashboard's Hijri header; segment by past category so it feels personal, not mass.

Measure: redemption rate and occasion-period revenue vs a normal period.

There are three ways a business can send on WhatsApp. Knowing which one you're on explains what you can automate, how you're billed, and who you talk to for support.

The three options

• WhatsApp Business App — the free mobile app for very small businesses. Manual, one device, no automation or CRM. Not what Relay uses.
• WhatsApp Business Platform — Cloud API — Meta-hosted, programmatic access for automation, campaigns, and multi-agent inboxes. This is today's standard and what Relay runs on.
• WhatsApp Business Platform — On-Premises API — the older self-/partner-hosted version. Meta is sunsetting it; new features and template sending have been moving off it. New deployments should always be on the Cloud API.

What a WABA is

A WhatsApp Business Account (WABA) is the container for your phone number(s), message templates, quality rating, and settings. It lives inside a Meta Business Portfolio (Business Manager). One business can have multiple WABAs; a WABA can hold multiple numbers.

How Relay fits

Relay connects you to the Cloud API through Cequens as a Meta Business Solution Provider (BSP). You get onboarding, number provisioning, template management, and a shared inbox without running any WhatsApp infrastructure yourself.

Related: Phone numbers, WABAs & number hosting · Partner types · Help: Connect a WhatsApp number

Meta lets businesses reach the WhatsApp Business Platform in a few ways, organised under the Meta Business Partners program. The model you pick decides who hosts messaging, who bills you, and how much of the plumbing you own.

The partner models

• Solution Partner (classic "BSP" — Business Solution Provider) — a Meta-approved partner that provisions WhatsApp access, hosts messaging, provides tooling, and bills you directly (they settle with Meta on your behalf). Cequens is a BSP, and Relay is built on top of it.
• Tech Provider — builds software on the Cloud API, but the customer holds the direct billing relationship with Meta (your own WABA and credit line; the provider supplies the app layer).
• Direct / self-serve Cloud API — a business integrates with Meta itself and manages its own account, infrastructure, and billing. Most flexibility, most operational overhead.

A note on the names

"BSP" is the long-standing industry term; Meta's program language now uses Solution Partner and Tech Provider tiers, with a verified Meta Business Partner badge for approved companies. You'll hear all of these used interchangeably.

Why the choice matters in MENA

• Faster onboarding — an established regional BSP speeds number approval and verification.
• Local compliance — help with Arabic templates, KSA/UAE rules, quiet-hours and consent.
• One invoice & local support — consolidated billing and a team in your timezone.

Related: The WhatsApp Business Platform, explained · How WhatsApp billing works

To start a conversation outside the 24-hour service window, you must use a pre-approved message template. Templates are reviewed by Meta and grouped into three categories that also drive how they're billed.

The three categories

• Marketing — promotions, offers, product launches, newsletters, cart nudges, re-engagement. The most common category for campaigns.
• Utility — messages triggered by a transaction or account event the customer expects: order confirmations, shipping updates, appointment reminders, payment receipts.
• Authentication — one-time passcodes and login/verification codes only.

What a template contains

A name, a language, a category, and a body with {{1}}-style variables. Optionally a header (text/media), a footer, and buttons (quick-reply or call-to-action). You supply sample values so Meta can review it.

Why templates get rejected

• Promotional content submitted as Utility (wrong category).
• Variables at the very start/end, back-to-back variables, or missing sample values.
• Prohibited or regulated content, or content that looks like spam.
• Formatting/grammar issues or broken links.

In Relay you build, preview, and submit templates under WhatsApp → Templates; each shows its live status (Approved / Pending / Rejected).

Related: How WhatsApp billing works · Quality rating & messaging limits · Help: WhatsApp templates

Meta's billing model has evolved. You don't need the exact rates to plan well — you need to understand the categories, the free service window, and what triggers a charge.

From conversations to per-message

From 2022 WhatsApp billed per 24-hour conversation in four categories. As of 1 July 2025 Meta moved to per-message pricing: you're charged per template message delivered, priced by category (Marketing / Utility / Authentication) and destination country. Free-form service messages are not charged per message.

The 24-hour customer service window

When a customer messages you, a 24-hour window opens. Inside it you can reply with free-form service messages (no template needed, no per-message charge). Outside it, you must send an approved template, which is billed by category.

Free-er paths

• Free entry points — conversations that begin from a click-to-WhatsApp ad or a Facebook Page call-to-action open a longer 72-hour free window.
• Utility inside the service window — utility templates sent while a service window is open have been made free (from Nov 2024).

Related: Template categories & approval · Opt-in, consent & the policies

Meta protects users by scoring each sending number and capping how fast you can grow. Two things to watch: your quality rating and your messaging limit tier.

Quality rating

Each phone number carries a rating from the last 7 days of user signals (blocks, reports, "why did I get this"):

• 🟢 Green — High
• 🟡 Yellow — Medium
• 🔴 Red — Low (at risk of restriction)

Phone-number status can read Connected, Flagged (quality dropped, under review), Restricted (hit the limit or low quality), or Pending.

Messaging limit tiers

Your limit is the number of unique customers you can start conversations with in a rolling 24 hours:

• Trial / unverified — a small test volume (around 250 unique customers).
• Tier 1 — 1,000 unique customers / 24h
• Tier 2 — 10,000
• Tier 3 — 100,000
• Tier 4 — Unlimited

How you scale up (and down)

Complete business verification and keep High/Medium quality while regularly using ~50%+ of your current limit — Meta then auto-upgrades you to the next tier. If quality falls, limits can be reduced.

Related: Opt-in, consent & the policies · Display name, verification & the green tick

WhatsApp is a permission-first channel. Getting opt-in right protects your quality rating, keeps you compliant, and is the single biggest driver of deliverability.

The opt-in requirement

Meta requires opt-in before you message someone. The opt-in must make clear that the person will receive messages from your business on WhatsApp, and it must identify the business by name.

Acceptable ways to collect it

• A checkbox at sign-up or checkout (unchecked by default).
• A keyword the customer sends to your number ("START", "JOIN").
• IVR / phone, in-store, or an existing channel where they clearly agreed.

Whatever the method, log the consent (source + timestamp). Relay stores consent state on each contact and offers a double opt-in step (send_optin_request) inside Automations.

The policies

You're bound by the WhatsApp Business Messaging Policy and Commerce Policy. Regulated/prohibited categories include alcohol, tobacco, drugs, weapons, adult content, gambling, and certain supplements and financial products. No unsolicited or bulk spam.

Related: Quality rating & messaging limits · Foundations: consent & deliverability

Three related trust signals often get confused. Here's what each one is and how you get it.

Display name

The business name customers see on your messages. It must follow Meta's display-name guidelines — reflect the real business, avoid URLs or emoji-only names, and match your branding. A new display name is reviewed by Meta.

Business verification

Done in Meta Business Manager, this confirms your business is a real, registered entity (documents + domain). It's a prerequisite for raising messaging limits and for applying for the green tick.

Official Business Account (the green tick)

The green checkmark beside your name marks an Official Business Account (OBA). Meta grants it based on brand notability and authenticity — it isn't simply purchased. It boosts trust and can lift open/response rates. Without OBA, a verified business still shows its approved display name (customers just don't see the tick).

Related: Quality rating & messaging limits · Phone numbers, WABAs & number hosting · Help: WhatsApp onboarding

Every WhatsApp message sends from a registered phone number tied to a WABA. Here's how numbers work and what to prepare.

The structure

A WABA can hold several phone numbers, but each number belongs to one WABA at a time. Numbers live under your Business Portfolio.

Choosing a number

• A brand-new number — clean, dedicated to WhatsApp Platform.
• Migrate an existing number — including one currently on the WhatsApp Business App. Migration frees it from the app and registers it on the Platform (you lose app-only chat history).

The number must be able to receive an SMS or voice OTP to register, and must not be active on regular WhatsApp or another WABA.

Registration & the two-step PIN

Numbers are registered with a 6-digit two-step verification PIN that prevents anyone else from re-registering them. Keep this PIN safe.

Hosting

On the Cloud API the number is hosted by Meta (through your BSP). With Relay/Cequens, provisioning, OTP, and the PIN are all handled inside Embedded Signup during WhatsApp onboarding — no manual Meta setup.

Related: The WhatsApp Business Platform, explained · Display name & verification · Help: Connect a WhatsApp number

Almost all business SMS is A2P. Knowing the path a message takes explains why routes, sender IDs, and delivery receipts matter.

A2P vs P2P

• P2P (person-to-person) — normal phone-to-phone texting between individuals.
• A2P (application-to-person) — messages sent from software or a business to a person: OTPs, order alerts, marketing. This is what Relay does, at scale, with tracking.

The delivery chain

A single A2P message hops through several parties before it lights up a phone:

1. Your brand — you send via a Relay campaign, automation, or the API.
2. Aggregator / provider — Cequens, which holds carrier-grade routes across MENA.
3. Interconnect / SMSC — the operator's short-message service centre queues and forwards.
4. Destination mobile operator (carrier) — delivers to the subscriber.
5. Handset — and a delivery receipt (DLR) flows back up the chain.

Why the route matters

Not all routes are equal — direct/wholesale routes deliver reliably with real DLRs, while cheap "grey" routes drop messages or fake receipts. Cequens provides carrier-grade A2P routes in the region, and Relay routes each message through the best available carrier connection for you.

Related: Delivery receipts & message statuses · Sender IDs explained · Help: SMS in Relay

The sender ID is what appears as the sender on the recipient's phone. Choosing and registering it correctly is the single biggest lever on trust and deliverability.

The types

• Alphanumeric sender ID — up to 11 characters of your brand name (e.g. RELAY). Branded and trusted, but one-way — recipients can't reply. The default for A2P branding in MENA.
• Long code (long virtual number) — a standard mobile number. Supports two-way replies; lower throughput.
• Short code — a 4–6 digit number. High throughput, often for OTP and high-volume campaigns; leased and registered per country.

Dedicated vs shared

A dedicated sender is exclusive to you (full control, consistent branding). Shared pools are cheaper but you don't control the number and can't brand it.

Registration is mandatory in the GCC

Most Gulf operators require sender IDs to be pre-registered / whitelisted (KSA via CITC, UAE via TDRA, etc.). Unregistered IDs are typically blocked or replaced with a generic label. Arabic sender IDs are supported in some markets.

Related: Deliverability & MENA regulation · Help: Request a Sender ID

SMS has hard character limits that depend on the alphabet you use. Arabic and emoji cost more room than Latin text — this directly affects how many message "parts" you pay for.

Two encodings

• GSM-7 — the standard 7-bit alphabet. 160 characters in a single SMS. Latin letters, digits, basic punctuation.
• UCS-2 / Unicode — required for Arabic, emoji, and other non-Latin scripts. 70 characters in a single SMS.

Concatenation (multipart)

Longer messages are split into segments and reassembled on the handset. The join header eats a few characters, so each part shrinks:

• GSM-7 multipart: 153 chars per part
• UCS-2 multipart: 67 chars per part

How this hits billing

You're charged per segment, not per message. A 300-character Arabic message = 5 parts (67 each) → five times the cost of one. Keep Arabic tight, or watch the live part counter in Relay's composer.

Related: Delivery receipts & message statuses · Help: SMS templates

A delivery receipt (DLR) is the status the carrier returns for each message. Reading them correctly is how you measure real reach — not just what you sent.

The lifecycle

1. Submitted — accepted by Relay/the provider.
2. Sent — accepted by the carrier (handed off).
3. Delivered — confirmed on the handset. ✅
4. …or a terminal failure: Failed, Rejected, Expired, or Unknown.

Common non-delivery reasons

• Invalid or inactive number.
• Handset off / out of coverage (message expires after the retry window).
• DND / blocked, or sender ID not permitted on that network.
• Content filtered, or insufficient balance.

Some routes deliver DLRs late or not at all — another reason route quality matters.

In Relay

Statuses surface in Message Explorer and in campaign performance; DLRs flow back internally over the messaging bus and can be exported for reconciliation.

Related: A2P & the delivery chain · Deliverability & MENA regulation · Help: Messages Explorer

Deliverability is getting the message to the handset — and in MENA it's as much about compliance as it is about routing. Regulators actively filter non-compliant A2P traffic.

The regulators

Each market has an authority that governs A2P SMS and sender IDs: KSA — CITC/CST, UAE — TDRA, Bahrain (TRA), Oman (TRA), Qatar (CRA), Kuwait. They mandate sender-ID registration, may replace or block unregistered IDs, and enforce consent and content rules.

DND & opt-out

Honour STOP / unsubscribe and maintain suppression lists. Relay stores opt-out state per contact and supports keyword opt-out, so unsubscribed customers are automatically excluded.

Quiet hours & Ramadan

Marketing SMS must respect legal quiet hours — e.g. roughly KSA 09:00–22:00, UAE 07:00–21:00, Qatar 08:00–21:00, with extra Ramadan sensitivity. Relay's quiet-hours engine holds sends until the allowed window opens in each recipient's timezone.

Content & links

Avoid prohibited/regulated content. Public URL shorteners are sometimes filtered — Relay uses its own ShortLink domain so links stay trusted and trackable.

Related: Sender IDs explained · Delivery receipts & statuses · Foundations: consent & deliverability

SMS and WhatsApp aren't rivals — they're a toolkit. The trick is matching the channel to the job.

Where SMS wins

• Universal reach — works on any phone, no app or internet required.
• Reliability for critical messages — OTPs and time-sensitive alerts.
• Fallback — reaches customers who don't have WhatsApp or where a WhatsApp send fails.

Core SMS use cases

• OTP / 2FA — login and verification codes.
• Transactional — order, shipping, delivery, and appointment updates.
• Time-critical alerts — outages, price drops, back-in-stock.
• Broad promotional reach — a short, branded blast.

When to reach for WhatsApp instead

Rich media, two-way conversations, branded templates with buttons, and higher marketing engagement — see how WhatsApp billing works and template categories.

Related: Encoding & length · Knowledge Base: WhatsApp & Meta Essentials