Delivery across every channel

Delivery across every channel is TrailGuide's send layer: one message can reach a person over push, email, SMS, Slack, or a custom outbound HTTP call, through whichever provider you already send from. You define the message and pick the audience once, and the send layer routes it to the right channel and provider from there.

The point is reach without a rebuild. TrailGuide does not replace your engagement platforms, it fires into the ones you already run. A multi-step journey or a broadcast can touch people wherever they actually pay attention, and your existing templates, domains, and deliverability keep working underneath.

Five channels, one message

A single message definition can go out over any of five channels. Push and email carry the everyday lifecycle work. SMS is there for the moments that earn an interruption. Slack lets a message land in an internal channel, which is useful for alerts and for looping a human coworker into a flow. The fifth channel is a custom outbound HTTP call, covered below.

• Push, for in-app and mobile nudges.
• Email, for richer lifecycle messages.
• SMS, for time-sensitive, high-intent moments.
• Slack, for internal alerts and human handoffs.
• Custom HTTP, for connecting data out to any endpoint you name.

The providers you already send from

Each channel can run through many providers. TrailGuide supports the common engagement platforms (Braze, Iterable, Customer.io, OneSignal, and more), so a team at Northwind Outfitters can keep sending push through the provider it already trusts while TrailGuide decides who gets what, and when. You bring the account, TrailGuide orchestrates on top of it.

Before a single message goes out, the send layer runs a verify step on the connection and a connector test against the provider. If a credential is wrong or an endpoint is unreachable, you find out at setup, not halfway through a launch to your win-back audience. Setup problems surface as setup problems, which is where they are cheap to fix.

A custom HTTP channel for connecting data out

The custom HTTP channel turns a message into an outbound request. You define a body template with tokens, TrailGuide fills those tokens from your system fields at send time, and it posts the result to the endpoint you name. That is how you wire TrailGuide into anything that is not a standard engagement provider: a webhook, an internal service, or a partner API.

{
  "channel": "http",
  "url": "https://hooks.example.com/lifecycle",
  "method": "POST",
  "bodyTemplate": {
    "userId": "{{user_id}}",
    "segment": "{{segment}}",
    "event": "trial_day_5_nudge"
  }
}

Safe by construction

Letting a marketer point a send at an arbitrary URL sounds risky, so the custom HTTP channel is not a raw fetch. Every request routes through an SSRF-safe fetch that blocks private, loopback, and cloud-metadata IP ranges and pins DNS to defeat rebinding attacks. An address that resolves to your internal network or a metadata endpoint is refused before any bytes leave.

One send layer under the whole harness

Because every channel shares one send layer, everything else composes with it. Frequency and engagement caps, holdouts, and guardrails apply the same way whether a message is a push or an HTTP call, and a single journey can switch channels between steps. Delivery breadth is what lets the marketing harness meet people where they are without asking you to abandon the stack you already run.