Delivery is not your product
Sender records, bounce handling, a template store, a retry policy that does not double-send. Four sprints of work that your customers will never see and your competitors already have.
For software and product teams
Your backend knows what to say.
QuickGrow is the part that says it. One call from your server sends email, SMS or WhatsApp; the delivery status comes back as a value you can read and as a signed callback to your endpoint. The onboarding sequence your marketer keeps rewriting lives on a canvas, not in your repository.
One endpoint, three channelsSigned delivery callbacksThirty tools for an AI agent
01What messaging costs a product team
None of this is on your roadmap.
Every product ends up sending mail. Almost none of them meant to build a sending system, and the work never appears in a release note anyone is proud of.
Three channels, three builds
Email went out through one provider. Then someone asked for a one-time code over SMS. Then your Bangladeshi customers asked for WhatsApp. That is three integrations and three sets of delivery reports.
Copy ships as code
The day-three onboarding email is a string in your repository. Changing one sentence means a branch, a review and a release, so the sentence never gets changed.
Nobody can say whether it sent
Support asks whether the verification code went out. The honest answer lives in a log file, on a good day, and the customer is still waiting.
02From your server to a phone
Four things to wire up, once.
There is one send endpoint and it takes all three channels. After that, nothing about adding SMS or WhatsApp looks like an integration project.
Make a key
Create an API key in the workspace and tick only what it needs — send messages, read messages, write contacts, manage callbacks. Give it a requests-per-minute ceiling, a list of source addresses allowed to use it, and an expiry date. Rotating a key keeps the old one alive for a grace period, so a deploy never races a credential change.
Post the message
Say which channel, who it goes to, and either the content inline or the id of a saved template plus the values for its placeholders. Email can carry a sender name on a domain you have verified, a reply-to address, and up to ten attachments totalling seven megabytes.
Read what comes back
The response carries the message id and its status straight away. Ask for that id later and you get the current status, when it was sent, when it was delivered, and — if it failed — the reason and a failure code you can branch on. Your own reference data comes back untouched on every read.
Be told when it changes
Point a callback at your server and subscribe to sent, delivered, failed and bounced. Each delivery is signed with a secret only you and QuickGrow hold, and carries the time it was signed, so you can verify the request really came from us before you act on it.
Channels
One call. Whichever channel suits the message.
A password reset is an email. A login code is an SMS. An order update is a WhatsApp utility template. Same endpoint, same response shape, same reporting — you change one field and the rest of your code stays where it is.
- Retries that never double-send: repeat the same request with the same retry key and the second one replays the first response instead of sending again. Good for 24 hours, which outlives any sane retry loop.
- Every keyed response tells you how much of your request allowance is left, so a backlog can pace itself instead of being refused.
- Your code sends a template id and a set of values; the people who write the copy edit the wording in the app. No release involved.
03What your server gets back
No guessing about whether it arrived.
Two ways to find out, and you can use both. Ask whenever you like, or have the answer pushed to you the moment it changes.
In the response
- The message id, its channel, its current status and the time it was created.
- The tags and the reference data you attached, echoed back exactly as you sent them.
- For email, the send is attempted inline — you learn immediately if it was refused.
When you ask later
- Fetch one message by id for its current status and its timestamps.
- List messages filtered by channel, by status, or by a created-at range, paged with a cursor.
- The statuses are queued, sending, sent, delivered, opened, clicked, bounced and failed.
Pushed to your endpoint
- Subscribe a URL to sent, delivered, failed and bounced, and pick the events per subscription.
- Each delivery is signed with that subscription’s own secret so you can verify it before acting.
- A delivery your server does not accept is retried four more times, spread across the following half hour.
Journeys
Onboarding sequences that live outside your repository.
A journey is a trigger, some waits, some sends and some branches, drawn on a canvas. Your marketer rewrites the day-three email at four in the afternoon and nobody opens an editor. The canvas below is a cart-recovery journey from the demo workspace, but a trial-onboarding sequence is built from exactly the same blocks.
- Triggers to build on: a contact created or updated, a tag added or removed, a form submitted, a campaign opened or clicked, a date held on the contact record, or started by hand.
- Steps: send on email, SMS or WhatsApp, wait, add or remove a tag, update a field, branch on a condition, or split a percentage down each path.
- A step can call a URL on your own server — your method, your headers, your body — so a journey can write back into your product mid-flight.
04AI agents
Point an LLM at the workspace and let it do the work.
QuickGrow speaks the Model Context Protocol. Connect Claude — or any client that speaks it — and it gets thirty real tools backed by the same services the app itself runs on. It signs in the way any other connected app would: a standard authorisation screen, a set of scopes, and a connection you can revoke. This is not a chat box bolted onto a dashboard; it is your workspace, operable by an agent.
What it can look at
- Search contacts and leads, and preview how many people a set of segment rules would match before anything is saved.
- List campaigns across email, SMS and WhatsApp, and pull the report for any one of them.
- Read the dashboard overview and the channel comparison for a date range it names.
What it can change
- Create a contact, a lead, or a saved segment from rules it worked out.
- Write a template, and draft a campaign against a saved segment.
- Schedule a campaign for a time you name, or cancel one that is already scheduled.
What it cannot do quietly
- Sending or scheduling takes two steps: the tool first returns a preview of what would go out, and only a matching confirmation — valid for ten minutes — actually sends it.
- Each capability is approved once by a person in your connected-apps settings before the agent can use it at all.
- A connection is scoped and per-brand: read-only stays read-only, and it reaches only the brands you connected it to.
30 tools Scoped sign-in Human confirm before a send Rate limited per connection Audit trail Per-brand separation
05Three ways to send
Which one do I reach for?
They are not competing. Most product teams end up using the first two together, and hand the third to whoever runs marketing.
| REST API | Journeys | AI agent | |
|---|---|---|---|
| Fired by a call from your code | Yes | No | No |
| Changed without a deploy | No | Yes | Yes |
| Who it reaches | One named recipient | One contact at a time | A saved segment |
| Timing | The moment you call it | Waits and date triggers | Send now or schedule |
| Delivery pushed back to your server | Yes | No | No |
| A person has to confirm before it sends | No | No | Yes |
| Best for | Codes, receipts, alerts | Onboarding and win-back | Analysis and drafting |
Shared inbox
People reply to no-reply addresses.
Constantly. Inbound messages on all three channels land in one conversation list instead of three places nobody watches, so a reply to an account alert reaches a human rather than a mailbox.
- WhatsApp, SMS and email threads in a single list, whichever channel they arrived on.
- Assign a conversation to a named colleague, tag it, resolve it, reopen it.
- The thread stays attached to the contact record, so you can see what was sent before the reply.
06Questions an engineer asks first
The things worth knowing before you write any code.
How does my backend actually send a message?
One POST to the messages endpoint, authenticated with an API key header. You name the channel — email, sms or whatsapp — the recipient, and either the content inline or a saved template id plus the values for its placeholders. The response comes back with the message id and its status. The request and response shape is the same for all three channels, so adding SMS after you have shipped email is a field change, not an integration.
What happens if my retry loop fires the same request twice?
Attach a retry key to the request and a repeat of it replays the original response instead of sending a second message. That holds for 24 hours after the first call, which is longer than any retry policy you are likely to write. Without the key, two identical requests are two separate messages — so use it on anything a queue might redeliver.
How do I find out that a message was delivered?
Either ask or be told. You can fetch a message by id at any point, or list messages filtered by channel, status and date range with a cursor for paging. Or you subscribe one of your URLs to sent, delivered, failed and bounced: each event is signed with that subscription’s secret and carries a timestamp, and a delivery your server does not accept is retried four more times over the following half hour. Every attempt is logged with the response it got, and you can send a test delivery or roll the secret from the app. Only messages sent through the API raise these events, so campaign traffic will not swamp your endpoint.
Stop maintaining a sending stack.
Get a key, send one message, and watch the delivery come back to your own endpoint. You pay a platform fee plus the channels you actually send on — and bring your own mail server and the platform fee is all there is.