Quick answer: OTP abuse rarely starts at the API — it starts at two surfaces a single operator can change: the message template recipients read, and the resend action that re-issues codes. Devotel Orbit's OTP approvals surface lets your organization route both through a four-eyes queue: a requester submits, a second supervisor approves or rejects, and only then does the change go out. The server enforces that the approver is never the requester. It is a control your organization owns and switches on — not a platform-mandated compliance claim.
Most OTP risk postures focus on the receiving side — SIM-swap signals, fraud monitoring, rate limits on inbound verification attempts. Those matter. But there is a second class of abuse that enters from the inside: someone with dashboard access changes what an OTP message says, or fires resend after resend until a code leaks, an aggregated invoice spikes, or recipients get spammed. This post walks the two surfaces involved, why a two-person gate is the right shape for them, and where the queue lives in Orbit.
The two highest-abuse-leverage OTP surfaces
An OTP program has two surfaces where one person's edit changes what reaches end users:
- Message templates. Each channel carrying your verification codes (SMS, voice, WhatsApp, email) renders from a template. Whoever can edit the body can change what every recipient sees — add a link, change the sender framing, or reword the copy into something your reviewers never approved. Template edits are the highest-leverage content surface in the product.
- Resend bursts. A verification resend re-issues a code to the same number. Individually legitimate — users mistype, messages lag — but unbounded resends are how a single session turns into cost inflation, recipient harassment, or a window for brute-forcing the code.
Both are normal operations. The question is whether one operator, acting alone, should be able to push either one to production. For a lot of teams the honest answer is no — and that answer has a name: the four-eyes, or two-person, rule.
Why a second supervisor gate is the tenant-owned control
The four-eyes rule does not say templates or resends are forbidden. It says they require two people: one requests, a second approves. Devotel Orbit implements this as an organization-level policy you switch on, because verification posture is tenant-owned — the control is yours to enable, scope, and set thresholds for, not a platform-wide mandate.
The one rule that is hard-coded is the one that makes the gate mean anything: the approver can never be the requester. Self-approval is refused by the server, so an operator holding owner or admin rights cannot queue a change and sign it off themselves — the second pair of eyes has to belong to a different person. Approvals are restricted to supervisor roles (owners and admins); everyone else can submit requests, and can read whether the policy is on so they know their action will be gated.
For resend bursts the policy is tunable per organization: you set how many resends within a rolling window is acceptable, and only sends past that threshold park in the queue. Routine re-issues under the threshold pass straight through — the gate catches bursts, not normal retries.
The workflow: queue, review, release
The gate operates the same way on both surfaces, and it reads the same as the campaign-approvals queue elsewhere in the dashboard:
- A requester submits. A teammate edits a per-channel OTP template body, or a resend crosses the burst threshold. Instead of applying directly, the change parks in a pending queue. Template entries carry the exact rendered body inline, so the supervisor judges the copy a recipient would actually read, not a diff against something else.
- A supervisor reviews. An owner or admin opens the queue, ordered oldest first, and approves or rejects with an optional reason. Supervisors see a pending list; everyone with access sees whether the policy is on.
- The decision replays or drops the work. Approval replays the queued action down its normal path — the template update applies to the profile, the resend re-issues through the standard verification chain. Rejection closes the request with the reason recorded. Either way the organization gets an auditable record of who asked, who decided, and why.
The result: the exact copy that leaves, and every above-threshold resend, passed through two named people.
Where it lives
In the dashboard, supervisors work from the OTP approvals queue at /<locale>/verify/approvals — the same console family as the campaign-approvals surface, so the review pattern is familiar. The public API the queue talks to sits under /api/v1/verify/approvals: pending list, approve, reject, plus a settings resource (readable by any authenticated member, writable by owner/admin) that holds the on/off switch and the resend-burst threshold and window. If you integrate the verification flow, the Verify API guide covers the send-and-check loop this gate wraps.
A control you own, not a platform claim
This framing matters. Orbit treats verification posture as tenant-owned: the four-eyes gate is a control your organization opts into, with thresholds you set — one of the small number of deliberately hard-coded rules is restricted to the approver-equals-requester refusal. Nothing here is a platform-wide compliance claim, and the gate does not change where a message goes: it only decides whether a queued change may proceed down the normal delivery path.
Teams that turn it on usually pair it with the receiving-side signals — fraud monitoring and the receive-side checks the sibling post on Verify APIs and OTP fraud monitoring walks through — so both directions into the OTP flow have a posture you chose, not a default you inherited.
Frequently asked questions
What does the OTP approvals gate cover?
Two surfaces: new or edited per-channel OTP message templates, and verification resend bursts that exceed your organization's resend threshold within its rolling window. When the policy is on, both park in a pending queue until a supervisor approves or rejects them.
Can an operator approve their own request?
No. The server refuses self-approval — the approving supervisor must be a different user than the requester. Approvals are also restricted to supervisor roles (owner or admin); non-supervisors can submit requests and read the policy, but cannot decide it.
Are all resends gated, or only bursts?
Only bursts. You configure a threshold (for example, more than a set number of resends per verification within a window) and only sends past it enter the queue. Routine resends under the threshold go straight through.
Is this a platform-enforced compliance requirement?
No. It is an organization-level policy you switch on and tune, consistent with Orbit's tenant-owned-controls model. The one hard-coded rule is the self-approval refusal, which is what makes the gate a genuine two-person control.
Does approval change how the message is delivered?
No. Approval only releases the queued work into its normal path — an approved resend re-issues through the standard verification chain, and an approved template applies to the verification profile. The gate sits in front of the change, never on the wire.
The takeaway
OTP abuse enters through two inside surfaces — template copy and resend volume — and both are addressable with the oldest control in the book: two people. Devotel Orbit's OTP approvals queue puts that control behind a policy your organization owns, with a server-side guarantee that the second pair of eyes belongs to someone else.