Skip to main content
This guide takes you from a new SuprSend account to a notification sent from your own code. By the end, you’ll have built a template and a workflow in SuprSend, and added two calls to your backend: one that identifies a user, and one that triggers the workflow. You’ll then confirm in logs whether the notification was sent. Everything in this guide runs in your Sandbox workspace and uses the email channel. Because it’s a sandbox, an email vendor is already connected — there’s nothing to set up before you send.
This guide assumes you’ve read Core concepts. It uses template, user, workflow, and logs without redefining them.

Set up

Sign up and start in Sandbox

Create your SuprSend account. Three workspaces are created automatically — Sandbox, Staging, and Production. Switch between them from the top navigation bar. Stay in Sandbox for this guide: it already has an email vendor connected, so there’s nothing to configure before you send.

Get your credentials

SuprSend uses different credentials for different jobs. You won’t need all three. Go to Developers → API Keys and copy your Workspace Key and Workspace Secret — that’s what the code in this guide uses by default. If you are generating an API Key instead, it’s on the same page and is shown only once, so copy it before closing the dialog. Store them as environment variables:
.env

Build the notification

One email template with a single variable, order_id, and a workflow that sends it.
Open Agent with Cmd+/ and paste:
Agent builds the template first, then the workflow that uses it, and commits both.
SuprSend Agent completing six tasks to create and commit the Order Shipped template and the Order Shipped Notification workflow, ending with both slugs

Agent building and committing both, then reporting the slugs

Order Shipped template marked Live, with the input payload on the left and the preview rendering Order #ORD-1234 is on its way

The committed template

Order Shipped Notification workflow marked Live, showing the Trigger via API node and an Email node using the order-shipped template

The committed workflow

You now have a live template, order-shipped, and a live workflow, order-shipped-notification.
Delays, batching, branches, and multi-channel routing are all added as extra nodes — see Design workflow. For ready-made examples, browse the sample library from Workflows → New Workflow → Use Sample Workflow.

Identify a user and trigger the workflow

Two calls go into your backend. The first tells SuprSend who your user is and how to reach them. The second runs the workflow you just built.
One prompt writes both calls into your codebase. Paste it into Claude Code, Cursor, Windsurf, or any other AI editor you use.
Recommended: connect your editor to SuprSend first. Your agent can then confirm the workflow exists and check the user was created, instead of taking your word for it. The prompt works without it.
Get a Service Token from Account Settings → Service Tokens. It’s shown only once, and it’s account-wide — it belongs in your editor’s configuration, not in your application code or your .env file. Requires Node.js 18+.Claude Code — run in your terminal, not inside a claude session:
Cursor — add to ~/.cursor/mcp.json, creating the file if it doesn’t exist:
mcp.json
Windsurf — add the same block to ~/.codeium/windsurf/mcp_config.json, without the mcpServers wrapper, then click Refresh.Confirm it worked by asking your editor to list your SuprSend workflows. Full setup: MCP server.
No codebase yet? Use the cURL example in the next tab — it runs both calls from your terminal with nothing to install.
Your editor writes the same two calls shown in the next tab. Read the diff before you run it.
Sandbox already has a user created from your registered email. You’re making your own anyway — the point of this step is your code creating the profile, not the profile existing.

Confirm delivery

Open Logs in the dashboard. Under Requests you’ll see both of your calls — user_update for the user you created, and workflow for the trigger.
SuprSend Logs page on the Requests tab, showing a workflow request and a user_update request, both completed
Open the workflow execution to watch it run node by node, and to see the email reach the recipient.
Workflow execution log for order-shipped-notification, showing the email node succeeding and the message delivered
Now check that inbox. The email is there, sent by code you wrote.
Sandbox is a trial workspace: it expires 28 days after signup and has capped usage. Everything you built here — the template, the workflow, and the two calls in your backend — works the same in Staging and Production once you connect your own vendor.

Next steps

Go live

Move to Staging and Production, connect your own email vendor, and run through the pre-launch checks.

Add an in-app inbox

Show notifications inside your product. Needs frontend SDK work on top of the backend integration here.

Trigger with events

Send one event and let it start several workflows, instead of naming one workflow per call.

Let users choose

Preference categories and channel opt-outs, so people control what reaches them.

Troubleshooting

The slug in your trigger call doesn’t match a live workflow. Either it’s a typo, or the workflow is still a draft. Open it and check the badge reads Live — if it doesn’t, commit it.
You’re using the wrong credential for the path you’re on. Backend SDKs take the Workspace Key and Secret. The REST API takes an API Key as Authorization: Bearer. A Service Token works for neither — it’s for the CLI and MCP server only.
Sandbox only delivers to verified channels — a short list you control at Developers → Verified Channels, up to 5 per channel type. If the recipient’s address isn’t on that list, nothing arrives.
A completed execution means every node ran, not that a message was delivered. A channel only sends when all four are true:
  • The template has live content for that channel
  • The user has an identity for it — an email address, in this case
  • The user hasn’t opted out
  • A vendor is connected
The workflow execution log names which one failed. The most common cause here is a user synced without an email address, so check the profile under Users first.
The key in your trigger’s data doesn’t match the variable in your template. data must contain order_id for {{order_id}} to resolve. Open the message in Logs → Messages and use Message preview to see exactly what rendered.