Orbit's integrations hub already covers the no-code path — Zapier for turning any Orbit webhook event into an action in another app. The new n8n integration covers the other end of the spectrum: teams that run workflow automation themselves, extend it, and touch internals. It ships as a node pack, n8n-nodes-orbit, that you download from Developers → Connectors pre-wired to your tenant. Inside it you get an Orbit trigger node for incoming events plus action nodes that send messages and create contacts, authenticated with your existing Orbit API key. Where Zapier's pitch is "no code, hosted canvas, wide SaaS catalog," the n8n pitch here is "developer-owned instance, API-key auth, first-class nodes instead of generic HTTP requests." Both pair with Orbit; this post is about why the second one exists, what the node pack actually exposes, and three workflow recipes that run on a self-hosted instance.
When and do — the workflow primitives the node pack maps
A workflow engine builds on two primitives: when — a trigger fires a run — and do — nodes execute the steps. The Orbit node pack gives you both against your tenant, so the generic HTTP node stops being your only bridge.
The when: the Orbit trigger node starts a workflow from an Orbit event. That is any webhook event you have configured on your tenant — a new conversation, an inbound message, a completed campaign — delivered into n8n as the workflow's entry point. No polling loops, no hand-rolled webhook endpoint glued to a generic node.
The do: the action nodes cover two moves you build on constantly. Send a message — an SMS or WhatsApp message goes out from any node upstream, with the recipient, channel, and body mapped from the workflow's data. Create a contact — upsert a contact row when upstream systems produce a person — a CRM sync, a form intake, a list pull — instead of managing CSV imports. Both authenticate with your Orbit API key held as an n8n credential, so the key lives in n8n's credential store, not in workflow definitions.
These are the same actions a generic HTTP request node could attempt, but as first-class nodes they carry typed fields and validated output instead of a hand-assembled call you maintain by hand.
Three workflow recipes that survive a self-hosted setup
These three are the workflows teams build first on the pack. Each one is a template you can copy into your instance.
1. Voice-of-customer NPS collector. Trigger: an Orbit conversation ends. The trigger node fires, a wait step gives the customer breathing room, and the send-message action sends the NPS survey over SMS or WhatsApp. Inbound replies update the contact record via the contact-create action, tagging the score back to the contact profile. Because the trigger and send nodes are typed, the survey cadence lives in the workflow, not in a campaign.
2. Low-balance alert before an A2P send. Trigger: any upstream event — a scheduled n8n cron, a webhook from your billing tooling, a queue consumer. The workflow checks your Orbit wallet balance, and when it falls below a threshold you set, the send-message action pages your on-call channel or fires an ops email. The point: outbound A2P sends fail at send time when the wallet runs dry, so the alert needs to land before the campaign, not after.
3. Downstream webhook job. Trigger: a DSV-equivalent event — a delivery-status update or another Orbit webhook event — arrives via the trigger node. Action: enrich the payload, hand it to your internal systems, and upsert the contact with the latest state. This is the pattern that replaces the "glue HTTP endpoint" for teams already running n8n as their event router.
None of these is a template we ship — they are constructions on the primitives, which is the point of giving you nodes instead of a hosted canvas.
Self-hosting posture — where the key lives and how tenants provision it
The node pack is pre-wired to your tenant at download time, which is what keeps it from becoming a shared dependency you then have to lock down. The mechanics:
- Where the key lives. In your n8n instance's credential store. The workflow definition itself holds no secret — n8n resolves the credential at run time. If you self-host n8n, the host is yours; if you run n8n Cloud, it follows their credential-storage posture.
- Provisioning. The Orbit API key is a tenant-scoped secret your admin provisions once in the dashboard. The same key authenticates every node in the pack; there is no separate OAuth app to register and no per-node credential.
- Rotation and revocation. Rotate the key in your dashboard, update the n8n credential, and every workflow keeps running — nothing to re-download.
- Tenant isolation. The pack does not multiplex. A downloaded pack authenticates one tenant's key; a second tenant means a second credential, which keeps the pack tenant-isolated at the node-pack layer instead of the workflow layer.
This is the part that matters for compliance review: the secret chain is explicit, and the integration does not smuggle credentials into workflow definitions where version control or export logs could catch them.
How to wire the nodes into a workflow
- Download the node pack. In Orbit, go to Developers → Connectors and download
n8n-nodes-orbit, pre-wired to your tenant. - Install it into your instance. Add the pack to your self-hosted or n8n Cloud instance and register it as a community node pack.
- Store your API key as a credential. In n8n, create an Orbit credential carrying your API key — one credential for every node in the pack.
- Add the trigger node. Drop an Orbit trigger node as the workflow entry and pick the webhook event you want to start on.
- Add the action nodes. Wire send-message and create-contact nodes downstream, mapping fields from upstream data. Test against a sandbox key before you point at production.
Frequently asked questions
Does the n8n integration work with self-hosted n8n?
Yes. The node pack installs into any self-hosted or n8n Cloud instance and authenticates with your Orbit API key, held as an n8n credential.
What nodes does the pack ship?
An Orbit trigger node that starts a workflow from any configured Orbit webhook event, plus action nodes that send SMS or WhatsApp messages and create or update contacts.
How is this different from the Zapier integration?
Zapier is the no-code hosted path — a canvas over our webhook events. n8n is the developer-owned path — the pack runs in your own workflow instance with first-class nodes and API-key auth.
Where does my Orbit API key live?
In your n8n instance's credential store. Workflow definitions never carry the key; n8n resolves the credential at run time.
Does one node pack work for multiple tenants?
No. The pack you download is pre-wired to one tenant, and each tenant needs its own credential. That keeps tenant isolation at the pack layer, not the workflow layer.
What does it cost?
The node pack is included in your Orbit plan; it consumes your existing API rate and messaging usage. Check pricing for the message-cost side.
Resources
- n8n integration page — the registry entry this post expands on
- MCP server for communications — explainer — the other machine-facing surface for building against Orbit
- Pricing — usage costs for the messages the send action produces
- Shopify conversational commerce — cart recovery — the other integration-anchored post on this blog
Published 3 September 2026.