The CPaaS pre-send gate chain — what every message clears before dispatch

A send is a sequence of decisions, not a single handoff

Before a message leaves Devotel Orbit for the carrier, it passes through a pre-dispatch chain that asks whether the recipient can be contacted now, whether your organization has suppressed the destination, whether national-number checks apply, whether PHI controls are satisfied, and whether the sender is registered for that country. A failed check stops that send before carrier handoff; a scheduled or retried message starts the applicable checks again with current data.

That distinction matters when you operate more than one channel or market. A contact can be reachable at 10:00 in their local time but still be suppressed. A sender can be approved in one country while an alphanumeric sender is unregistered in the next. The chain keeps those decisions separate, gives each one a reason, and leaves the final delivery attempt to the carrier only after the applicable gates pass.

This is a marketing walkthrough of the order and the operator's next move. It is not legal advice. Your organization owns its consent, configuration, registrations, and regulatory decisions; Orbit supplies the checks and the evidence around them.

The gate chain at a glance

The exact set varies by channel, destination, sender type, and your organization's enabled controls. The practical order is:

1. Quiet-hours check — can this send land in the recipient's local window?
2. Suppression check — has the recipient opted out or entered a list that must not receive this traffic?
3. DNC check — when enabled and applicable, is the number on a Do-Not-Call source?
4. RND check — when enabled and applicable, was the number reassigned after consent was obtained?
5. BAA check — if your organization handles PHI in HIPAA mode, is an executed, in-term BAA on file?
6. country-registration check — does the sender meet the destination country's registration requirement?

These checks do not replace consent collection, content review, sender resolution, or carrier filtering. They are the pre-dispatch controls that can hold or reject an otherwise valid send. A check that does not apply is skipped; a check that is enabled and returns a blocking result stops the send rather than handing a questionable message to a carrier.

1. Quiet hours: is now the right local time?

Orbit resolves the recipient's local timezone and compares the planned delivery time with your organization's quiet-hours posture. For a non-voice channel, the window is a tenant-owned setting under Settings → Compliance → Quiet hours. Once enabled, the default is 08:00–21:00 for SMS and 09:00–21:00 for WhatsApp and Meta channels, unless your organization sets different hours. Email, fax, and push are not quiet-hours gated.

A send outside the window is held or rejected with a quiet-hours result rather than dispatched immediately. The response can include next_allowed_at, an absolute timestamp that is safe across daylight-saving changes. Use that timestamp to reschedule, or adjust the window when your documented messaging policy permits it. Preview a destination with GET /api/v1/compliance/quiet-hours/preview before launching a campaign.

This is recipient-local time, not the timezone of the person pressing Send. If the timezone cannot be resolved, your unknown_timezone_policy decides the non-voice result. Voice campaign traffic has a separate hard TCPA window, so do not treat a one-to-one messaging setting as a voice policy.

2. Suppression: has the recipient asked not to hear from you?

Suppression is the direct recipient-protection gate. Orbit reads the tenant's suppression list before dispatch, including records created by a STOP reply, a preference-center unsubscribe, a Consent API opt-out, a complaint, or an imported legacy list. A suppression entry is the operational fact the send path enforces; the related consent or opt-out record preserves when and how the decision was made.

The default scope for a phone-based opt-out is all, so a STOP on SMS can prevent later WhatsApp, RCS, voice, and dialer traffic to the same identity. An email-only import can remain scoped to email, while an explicit import channel can override the inferred scope. This prevents a channel switch from becoming a way around a recipient's request.

If this gate blocks a send, remove the recipient from the audience or resolve the suppression only after the recipient has provided a valid opt-in and your policy permits re-subscription. Do not delete evidence to make a campaign run. Review the suppression scope and consent history first, then retry with the same chain intact.

3. DNC: is this number on a Do-Not-Call source?

For a phone destination, the Do-Not-Call check can compare the number with your tenant's DNC and suppression sources and, when available, the federal, state, or TCR register snapshot. GET /api/v1/compliance/dnc/check reports the source and whether the number is on DNC; POST /api/v1/compliance/dnc/scrub applies the same check to a batch before a campaign.

DNC scrubbing is an explicit posture, not an invisible promise. The organization-level acknowledgment is off by default while no platform register snapshot is synced. In that state, the endpoint returns 403 DNC_SYNC_NOT_ENABLED until you enable dnc_sync_enabled, and a result backed only by tenant-curated sources must not be mistaken for a federal-register result. When a snapshot is synced, read federal_feeds_synced: true to confirm that the broader scrub is backing the response.

A number flagged by an applicable DNC source should leave the audience or be routed through your documented legal review. If the endpoint returns the synchronization gate, enable the per-organization acknowledgment or wait for the platform snapshot; do not interpret the blocked pre-flight as a clear number.

4. RND: did the number change hands after consent?

The FCC Reassigned Numbers Database check addresses a different question from DNC. It asks whether a US number was permanently disconnected after the date you obtained consent, which can indicate that the number now belongs to someone else. GET /api/v1/compliance/rnd/check takes the E.164 phone number and consent_date.

RND returns yes, no, or no_data. Only no carries the FCC safe-harbor signal. no_data means that no permanent-disconnect record is available, including when the feed is not synced; it is not an approval. The check is gated by rnd_scrub_enabled, and enabling it is rejected until the deployment has an RND feed configured, preventing a toggle from creating a false sense of coverage.

When an applicable result says the number was reassigned, do not send to it. Remove the destination or obtain a fresh, documented consent grant and evaluate it again. A fresh consent record changes the comparison date; it does not erase the earlier evidence.

5. BAA: is HIPAA-mode traffic covered?

The Business Associate Agreement check applies only when your organization has opted into HIPAA mode and declared PHI in scope. In that posture, an outbound send is blocked until the BAA is executed and still within its one-year term. The platform does not assume that every account handles PHI, so organizations that have not enabled HIPAA mode do not encounter this gate.

The BAA lifecycle is not_required, pending, executed, or expired. Only executed within the term satisfies the send gate. A blocked send returns 422 HIPAA_BAA_REQUIRED with a reason such as pending, expired, or not_signed. If the status cannot be verified, 500 HIPAA_BAA_GATE_DB_FAIL fails closed: the send remains blocked rather than risking an unchecked PHI transmission.

The operator action is in Settings → Compliance → BAA: attest that PHI is in scope, preview the agreement, execute it as an authorized owner, and wait for the lifecycle to report executed. Treat the BAA as a legal control and keep your organization's counsel in the loop; a platform status does not make a use case HIPAA-compliant by itself.

6. Country registration: is this sender approved for this destination?

The final market-specific check asks whether the sender identity is allowed in the recipient's country and channel. Call GET /api/v1/compliance/country-rules before planning a launch. Its registration value is none, recommended, or required for each country and channel:

• `none` means the destination accepts the sender without pre-registration.
• `recommended` means traffic can send without registration, but filtering or relabeling is more likely.
• `required` means an unregistered alphabetic sender is blocked until the country's registration is approved.

This is a sender-identity check, not a global country block. Numeric long codes that the carrier provisions follow a different path from alphabetic sender IDs. India, for example, can require an entity, header, and content template in its DLT regime; Saudi Arabia and the United Arab Emirates require their own sender-name and identity process. Read the live country row rather than copying a static table from an old launch plan.

When a required market blocks the send, the response can be a 422 with a market-specific code such as MESSAGING_SA_SENDER_NOT_REGISTERED or MESSAGING_AE_SENDER_NOT_REGISTERED. File the registration in Settings → Sender IDs or through the sender-ID registration API, track it until approved, and then retry. The carrier or regulator grants the approval; Orbit does not manufacture it.

What a blocked send tells you

A pre-dispatch rejection is useful when it identifies the first gate that stopped the send. The message did not reach the carrier, so retrying the same payload without changing the relevant condition will produce the same result. Use the returned code and timestamp to choose the smallest safe next step:

These outcomes are intentionally different. A quiet-hours hold is a timing problem; suppression is a recipient preference; DNC and RND are number-screening controls; BAA is a data-handling control; country registration is a sender-market control. Keeping them distinct makes campaign review faster and gives your compliance team an evidence trail instead of one generic "send failed" message.

How to build the chain into launch review

Use the same sequence when you prepare a campaign or a high-volume API send:

1. Resolve the audience and sender. Know the destination type, recipient country, channel, and sender identity before evaluating the gates.
2. Preview timing. Resolve recipient-local quiet hours and schedule inside the allowed window.
3. Check suppression and consent evidence. Confirm that opt-outs and cross-channel scopes are honored before adding a recipient to the audience.
4. Run number screening where applicable. Confirm DNC posture and RND feed state; do not treat no_data as a green light.
5. Confirm data-handling posture. If HIPAA mode is active, verify the BAA is executed and in term.
6. Read the market row. Check country registration for the channel and sender type, and start filings early when the value is required.
7. Send a small controlled sample. Keep the gate result and request ID with the campaign record, then expand only after the sample behaves as expected.

The checks are reusable guardrails, not a substitute for a launch policy. Your team still decides which audiences, content, markets, and senders are appropriate. Orbit makes those decisions executable at the point where a risky send would otherwise leave the platform.

Frequently asked questions

Do all sends run every gate in the same way?

No. The chain is ordered, but each gate is conditional. Quiet hours depend on the channel and organization setting, DNC and RND depend on phone destinations and their enabled feed posture, BAA applies to HIPAA-mode organizations, and country registration depends on the destination market and sender type. Non-applicable checks are skipped; applicable blocking results stop dispatch.

Does a pre-send block mean the carrier rejected my message?

No. A pre-dispatch block happens before carrier handoff. The response identifies the Orbit gate that stopped the send, so changing the relevant timing, recipient, BAA, or sender-registration condition is more useful than repeatedly retrying the same request.

Is RND the same as DNC or suppression?

No. Suppression records your organization's decision not to contact an identity. DNC checks a Do-Not-Call source. RND checks whether a US number may have been reassigned after consent. A recipient can pass one check and fail another, so the chain keeps their reasons separate.

What should I do when RND returns no_data?

Do not treat no_data as a safe-harbor approval. It means the database has no applicable permanent-disconnect record or the feed is not synced. Confirm the feed and consent posture before contacting the number, and follow your legal review process where the database cannot establish a result.

Does an approved sender registration cover every country?

No. Registration is per country, channel, and sender type. Read the live country-rules row before each market launch. A sender approved in one country can still be blocked with a required-market registration error in another.

Sources and further reading

• Send Gates — the full BAA, quiet-hours, DNC, RND, and country-rules reference.
• Messaging pre-send gate troubleshooting — route a rejected send to its first visible gate.
• DNC pre-flight troubleshooting — understand the register-sync acknowledgment.
• Sender-ID country matrix — plan per-country registration.
• HIPAA on a CPaaS — the BAA lifecycle and PHI controls.
• Opt-out and suppression management — keyword, preference-center, and import paths.