​

Pre-launch readiness for fallback chains

​

1. Which steps the preview reads: order 0 vs order >= 1

• order: 0 is the primary channel — the same value as the campaign’s top-level channel field. Readiness for the primary is checked exactly as before; it is excluded from the fallback-step probe so it is never probed twice.
• order >= 1 entries are the fallback steps — the only entries the fallback-chain probe extracts. Gaps and non-contiguous orders are fine; only relative ascending order matters.

{
  "channel": "whatsapp",
  "channels": [
    { "channel": "whatsapp", "order": 0, "fallback_on": "failed", "fallback_after_seconds": 300 },
    { "channel": "sms", "order": 1 }
  ]
}

​

2. What the dry-run preview checks per fallback step

curl -X POST "https://api.orbit.devotel.io/api/v1/campaigns/{campaign_id}/preview" \
  -H "X-API-Key: $ORBIT_API_KEY"

• Provider registered — a provider class exists on the platform for that channel. Missing provider → the step is flagged in the waterfall and a warning is added.
• Channel connected — the tenant actually has a working sender for that channel. For SMS and MMS this means a dedicated sending number; for RCS it means a verified brand agent. This is the check that was previously skipped for fallback steps: an SMS fallback with no sending number is no longer a silent green.
• Not unverifiable — channels with no probeable connection signal at all (for example WhatsApp or email, whose connection is gated by separate flows) are reported as null, not as a pass. A fallback SMS/MMS probe that cannot run (for example a transient error) also fails closed: the preview adds an advisory warning instead of reporting green.

​

3. Reading the preview response

{
  "warnings": [
    "Fallback channel SMS: No dedicated sending number attached — this campaign will send from the shared Devotel sender. Buy a number under Numbers → Buy for a dedicated sender ID and better deliverability.",
    "Cross-channel fallback configured for [mms] but no provider is registered for those channels."
  ],
  "ready_to_launch": false
}

{
  "channel_waterfall": {
    "primary": "whatsapp",
    "primary_provider_available": true,
    "primary_channel_connected": null,
    "cross_channel_fallback": ["sms"],
    "cross_channel_fallback_available": [
      { "channel": "sms", "provider_available": true, "channel_connected": false }
    ]
  }
}

• true — the step can send from a tenant-connected sender.
• false — flagged; the step ships nothing you verified.
• null — the preview cannot verify this channel’s connection (WhatsApp, email, and similar). It makes no claim either way.

​

4. Where the dashboard shows the same chain

​

5. Delivery-based fallback vs budget-downgrade fallback

​

Wire-up summary

• Build the ladder: Fallback chains guide.
• Advance triggers and windows: Campaign end-to-end guide, step 6.
• Other pre-launch gates (wallet, suppression, quiet hours, caps): Outbound compliance pre-flight checklist.
• Delivery vs budget-downgrade shapes: Fallback and cascade planes.