Skip to main content
Back to blog

Viber channel operator guide — tiers, senders, governance, and the first send

Running Viber programs on Devotel Orbit end to end — where Viber actually wins (Balkans and Eastern Europe plus the broadcast niche), the Tier 1 sender-ID vs Tier 2 branded Business account registration paths, promotions vs transactional vs one-to-one message classes, tenant-owned broadcast governance, the omnichannel inbox with queues and dispositions, and every common rejection class with its recovery route.

Orbit Editorial Team

Viber has a dedicated channel page in the docs and a first-class send path on Devotel Orbit, but until now the operating detail only lived inside the bundle posts — the beyond-SMS OTT roundup and the APAC channel matrix. This is the standalone operator guide in the same series as the Telegram, Messenger, Instagram, WeChat, and Slack guides: where Viber earns a slot in a 2026 stack, how the two registration paths differ, the three message classes a program should standardize on, the tenant-owned governance controls, and the rejection classes you will actually meet. The field-level contract stays in the Viber channel docs; this post is the operating layer on top.

Where Viber sits in a 2026 omnichannel stack

Viber's center of gravity is Central and Eastern Europe and the Balkans — Serbia's neighbor markets, Bulgaria, Greece, Ukraine, and the adjacent belt where Rakuten reports roughly a billion registered users concentrated. In those markets the practical question is not "is Viber a good channel" but "which channel does this customer actually open," and the answer is often Viber rather than SMS or WhatsApp. Its second proven niche is broadcast messaging: rich, branded one-to-many campaign sends to a habitual audience, priced as a Viber-native alternative to SMS volume.

Three properties make it a real business channel in its heartland rather than a nice-to-have. First, business messages arrive as branded, verified conversations — a registered sender name and avatar on the two-way tier, not a naked alphanumeric string. Second, the audience habitually opens the app, which is what converts a reachable number into an answered message. Third, the two tiers below share one endpoint, so the transactional OTP program you start on Tier 1 upgrades to branded two-way messaging without a client-code change.

The Orbit-side surface: sender-ID path vs Business-account path

Viber ships as two non-overlapping tiers behind the same POST /api/v1/messages/viber endpoint, and the platform routes each send to the right provider based on your tenant configuration.

Tier 1 — one-way basic messaging. Wholesale Viber-over-SMPP termination with an alphanumeric sender ID (up to 11 characters, e.g. OrbitDemo). Provisioning is near-automatic: no per-tenant Viber Business signup, outbound only, charged on delivered. The one per-tenant artifact is the sender ID allow-list — you email your organization ID and the ID you want to Devotel support, Devotel registers it with the upstream Viber aggregator, and it participates in SMPP sender resolution thereafter. Sends made before allow-listing fail at the aggregator and surface as a failed delivery status.

Tier 2 — two-way advanced messaging. The full Viber Business HTTP API with a branded sender (verified business name, logo, avatar), inbound replies, media attachments, and Viber's structured rich cards, carousels, and reply keyboards. This path is deliberately not self-serve: Rakuten Viber gates every branded Business sender behind a manual approval queue, and Orbit cannot register on your behalf silently. Your Devotel account manager coordinates the entire application — business display name, sender profile logo, destination markets, and trademark/domain verification artifacts plus sample message content when Rakuten asks. Typical end-to-end onboarding is 5–10 business days, and there is no expedited path, so plan campaign launch dates around the window and run Tier 1 traffic for time-critical sends in the meantime. Once Rakuten approves and Devotel attaches the issued auth token to your tenant, the same endpoint starts routing through the Business HTTP API — no code change.

The dashboard reflects the split: the Viber workspace under Messages and the connect card under Settings → Channels track a Tier-1-ready SMPP route and a Tier-2 business-name state separately, and the prerequisite banner names which registration step is still outstanding rather than showing a generic "not connected" notice.

Message classes: promotions, transactional, and one-to-one chat

Everything you send falls into one of three operating classes, and the class sets your sender path, governance, and billing exposure. The pricing page carries the current per-channel Viber rate (billed at your plan's per-message price; Tier 1 bills on delivered, Tier 2 rides BYO-token policy where Rakuten bills your Business account directly); check the pricing page for your plan's row rather than memorizing a number.

  • Transactional — OTPs, appointment confirmations, order and delivery alerts. Tier 1 fits this class well: text-only, sender-ID path, high deliverability, minimal governance overhead. Example: body: "Code 482913 is your login verification. It expires in 5 minutes."
  • Promotions / broadcast — campaigns and seasonal pushes. Tier 2 with a branded sender earns its registration window here: rich cards, carousels, and inline CTA buttons change the conversion profile of a broadcast, and a branded avatar survives scrutiny better than a bare sender ID. Example: a rich_media spring-collection card with an open-url button and media attachment.
  • One-to-one chat — conversational support replies inside a thread someone opened (or an inbound reply on a Tier 2 tenant with Viber chatbot capability). Example: a support agent answering "Thursday slots still open" in reply to an inbound customer question. The Tier 1 path cannot receive replies — chat on Viber requires the Business sender with chatbot capability confirmed during registration.

Some programs standardize on Tier 1 for transactional and Tier 2 for broadcast and chat simultaneously — the endpoint and envelope stay constant, and billing splits cleanly by tier on the same plan row.

Tenant-owned broadcast governance

The compliance posture on Viber is tenant-owned, the same as every other OTT channel on Orbit: the platform is the conduit, your organization owns cadence, opt-out, and approval discipline. The controls you actually operate:

  • Cadence and frequency caps — constrain how often a recipient receives a promotional Viber send at your organization level, so a broadcast program does not collide with its own transactional traffic.
  • Opt-out list discipline — when a Tier 1 sender ID returns failed with an unreachable-recipient reason (not on Viber, ID not allow-listed in market), record it in your tenant's opt-out/suppression surfaces just as the Telegram TELEGRAM_USER_BLOCKED guide instructs, and suppress future promotional sends rather than retrying blindly. Where a Tier 2 tenant has chatbot capability and inbound replies reach the inbox, treat an explicit "stop" reply as an opt-out in your tenant's suppression list and exclude the contact from future promotional sends.
  • Reply-approval inline with the inbox — for broadcast pushes that invite replies, route inbound Viber replies into the omnichannel inbox and let an agent disposition the reply before any follow-up outbound go out. That is where the next section picks up.

The cross-channel fallback chain you configure per organization (Viber → SMS, or a longer chain) re-runs the SMS opt-out and DNC check before falling through to SMS — so a tenant-owned suppression policy survives the channel hop rather than silently re-contacting the recipient on SMS.

Inbox-side: Viber threads in the omnichannel inbox

Every inbound Viber reply on a Tier 2 tenant normalizes into the same envelope as every other channel: channel: "viber", direction: "inbound", contact attached, landing on the standard message.received event. In the dashboard it joins the unified inbox alongside SMS, WhatsApp, and every other channel, so routing, assignment, SLA clocks, queues, and dispositions behave identically — the agent does not need a Viber-specific workflow. The broadcast-governance rule from the previous section closes the loop: when a tier-2 thread arrives, an agent reads the prior broadcast on the same timeline, replies in-thread, and marks a disposition; an explicit opt-out lands in the tenant's suppression list and governance continues from there.

Comparison reality check: where Viber covers what SMS cannot

The honest decision rule, matching the bundle posts:

  • Viber over SMS in its heartland — Serbia-neighbor markets, Bulgaria, Greece, Ukraine, and the CEE/Balkans belt — where the audience is demonstrably present and broadcast-rich formats matter. For OTP and delivery-notification programs aimed at those markets, Viber-over-SMPP reach frequently beats WhatsApp.
  • Viber where SMS literally cannot reach — as the bundle post's country matrix puts it, in some coverage-edge markets (Montenegro, Belarus in the APAC matrix's CEE column) Viber is the OTT channel that closes a gap SMS coverage alone does not close; SMS stays the fallback underneath the chain.
  • WhatsApp when WhatsApp already owns the segment — in markets where the audience defaults to WhatsApp, adding Viber is duplicate registration and governance surface for no incremental reach; run one channel and keep SMS as fallback.

That rule keeps the channel selection market-first, not brand-first, exactly as in the bundle posts.

Walkthrough: your first Viber send

From the dashboard. Open Messages → Viber in the dashboard. Confirm the prerequisite banner is green — for Tier 1 that means Devotel has allow-listed your sender ID (email support with your organization ID and the desired ID); for Tier 2 it means the account-manager-coordinated Rakuten registration has returned and the token is attached. Paste the recipient E.164 number, your allow-listed sender (or branded business sender), and the body text, and send. The message lands queued and the delivery-status webhook on your configured Settings → Webhooks URL settles delivered / failed.

From the Node SDK.

import { Orbit } from "@devotel-orbit/node";

const orbit = new Orbit({ apiKey: process.env.ORBIT_API_KEY });

const message = await orbit.messages.sendViber({
  to: "+14155552671",
  from: "OrbitDemo", // allow-listed Tier 1 sender (or branded Tier 2 sender)
  body: "Your appointment is confirmed for March 10 at 2:00 PM.",
});

console.log(message.data.id);     // msg_viber_a1b2c3d4
console.log(message.data.status); // 'queued'

queued means persisted and accepted, not delivered — the terminal state arrives on the webhook you configured, and Tier 2 inbound replies arrive on the same inbound webhook surface. Poll GET /api/v1/messages/{id} if webhooks are not consumable.

Common rejection classes and recovery

Keep this table beside the error codes you will actually see in the delivery log — every row below is from the Viber channel reference and the scope is deliberately limited to the documented classes:

  • `INVALID_RECIPIENT` (422) — empty to or a malformed E.164 number. Fix the recipient format and retry once.
  • `VALIDATION_ERROR` (422) — missing to/body or a malformed metadata payload. Correct the body against the request table in the docs and retry.
  • `CHANNEL_NOT_CONFIGURED` (503) — no SMPP route registered and no Tier 2 token stored for your organization. Complete Tier 1 allow-listing or wait for the Tier 2 token rather than retrying blind.
  • `RATE_LIMITED` (429) — a burst over your tenant's /messages/viber pool (50 requests/min default at the platform row). Honour Retry-After; stage bulk sends through the campaigns API.
  • `MESSAGE_SEND_FAILED` (502, Tier 2) — Rakuten rejected the send — malformed rich_media/keyboard payload, quota saturation, or a provider-side failure. Check details.viberStatus against the Viber reference, fix the payload or wait the quota window, then retry.
  • Unreachable recipient (`failed` delivery status) — recipient has no Viber installed, or the sender ID is not allow-listed in the destination market. This arrives as a delivery-status webhook, never a synchronous error. Trigger the configured cross-channel fallback chain (Viber → SMS) or drop the recipient; an organization-level fallback chain is the shipped remedy.

Recovery discipline: retry the transient classes (429, transient Rakuten 5xx), do not retry the policy/config classes (allow-list, registration, malformed payload) until the cause is fixed, and route unreachable recipients through fallback rather than looping on Viber.

The takeaway

Viber on Devotel Orbit is a first-class channel with two registration paths and one endpoint, a standard set of tenant-owned governance controls, and an inbox surface shared with every other channel. Pick it where the market says Viber is the habitual messenger — the Balkans and Eastern Europe belt, plus broadcast-rich campaign niches — and skip it where WhatsApp already owns the segment. Most programs standardize the Tier 1 transactional path first, upgrade to Tier 2 when the brand payoff justifies the 5–10 business-day Rakuten window, and run the rejection classes above against the channel reference as their runbook. The paired beyond-SMS OTT bundle post remains the decision layer; this guide and the Viber channel docs are the operating layer.

Published 1 October 2026.

Keep reading

Viber channel operator guide — tiers, senders, governance, and the first send — Orbit by Devotel