Let an AI agent send your customer announcements

Every reseller has had this morning. A carrier drops a service at 6am, you’ve got a rough idea who’s affected, and now you need to tell them before they tell you.

So you export a customer list, filter it by plan, cross-check it against who’s already churned or suspended, realise the export was from last Tuesday, do it again, and eventually paste something into a mail tool. Two hours later the notice goes out to a support queue that’s already full.

Writing the email was never the slow bit. It’s building the list, and then trusting it enough to hit send.

That’s the job an AI assistant is actually good at. It’s also the job most people are nervous about handing over, and fair enough. You can quietly fix a bad draft. You can’t unsend 1,200 emails.

What changes when an agent drives the API

We’ve built bulk email into the PracBill API so an assistant can do the list-building against live billing data instead of against whatever spreadsheet someone exported last week.

You describe who you want in plain English. Something like “everyone on a business NBN plan in Victoria who isn’t suspended”. The agent turns that into a filter set, tells you how many customers it matches, shows you the email as one of them will actually receive it, and then stops and waits for you.

Two hours turns into about two minutes, which is nice. What matters more is that the list comes out of your billing data at the moment you send, not out of a CSV that was right on Tuesday.

We spent most of the effort on the guardrails

Letting software send mail to your customers when that software also decides who the customers are is a risky thing to build. We designed the endpoints so the dangerous options simply aren’t there.

You can’t hand us a list of addresses

There’s no recipient field. You send filters, and we resolve those filters into actual recipients on our side, at send time. An agent can’t paste in a list it built somewhere else, and it can’t slip in an address that isn’t a live, emailable customer in your department. If you pass customer_ids it can only narrow the set, never widen it.

Filters come off a menu

GET /{api_key}/customer/bulk-email/filters returns the only fields we’ll accept, with their types and allowed values, and whether you can join rows with AND or OR. Anything else gets ignored rather than guessed at. The agent picks from a list we control instead of writing a query.

Preview actually previews

POST /{api_key}/customer/bulk-email/preview works out the audience without queueing anything. You get the real recipient count, a sample of who’s in it, and if you pass the subject and body, a merge render for the first recipient that’s identical to what the sender will produce.

So when someone approves a send, they’re looking at a number and a finished email, not a description of an audience that may or may not be what the agent had in mind.

The count is a promise

This is the bit I’d point at if you only read one section. When you queue the campaign you can pass confirm_count, which is the number the preview gave you. If the audience has changed since then, we fail the request instead of sending it.

Someone churns, someone gets suspended, someone signs up, all in the ten minutes between your agent drafting the thing and you getting round to approving it. Without that check you’d never know. With it, the send stops and asks again. Whatever a human approved is what goes out, or nothing does.

Nothing leaves during the request

Queueing a campaign writes the records and returns straight away. The actual delivery is done by a scheduled sender, so there’s a window where POST /{api_key}/customer/bulk-email/{id}/cancel pulls back everything that hasn’t gone yet. Handy when you spot the typo thirty seconds too late, which is when you always spot it.

The whole thing is three calls

Your agent makes the first two by itself. A person approves before the third.

# 1. What can I filter on?
GET /{api_key}/customer/bulk-email/filters

# 2. Who would this reach, and what does it look like?
POST /{api_key}/customer/bulk-email/preview
{
  "filters": [
    { "field": "state",         "value": "VIC" },
    { "field": "account_state", "value": "Normal", "join": "AND" }
  ],
  "subject": "Planned maintenance, Sunday 2am-4am",
  "content": "<p>Hello {{company}},</p><p>We're carrying out...</p>"
}

# -> { "count": 1240, "sample": [...], "render": { ... } }

# 3. Send that exact audience, or don't send at all.
POST /{api_key}/customer/bulk-email
{
  "filters": [ ...same... ],
  "subject": "Planned maintenance, Sunday 2am-4am",
  "content": "<p>Hello {{company}},</p><p>We're carrying out...</p>",
  "confirm_count": 1240,
  "scheduled_at": "2026-09-14 08:00"
}

Merge fields are {{field}}, so {{company}} fills in per recipient. scheduled_at is Melbourne local time, which saves the usual argument about whose 8am we meant.

Once it’s away, GET /{api_key}/customer/bulk-email/{id} gives you progress on a campaign, and the paged history endpoint lists what’s gone out, newest first.

Where the person stays

We wouldn’t hand an agent unattended send authority and we haven’t built the API to encourage it. The split that works is that the agent does the tedious, error-prone part, which is resolving an audience and checking it against live data, and a person does the part people are good at, which is looking at “1,240 customers” and a finished email and going yes, that’s right.

Couple of other things. Bulk email is capability-gated, so an API key needs bulk_email turned on explicitly and an existing integration key doesn’t quietly gain the ability to mail your customers. And we keep campaign request bodies out of the API logs on purpose, so what you send to your customers isn’t sitting in a log table afterwards.

Trying it

API access comes with the Pro and Enterprise plans. Every parameter and response is documented in the bulk email reference, and the rest of the platform is in the full API reference.

If you’ve already got an assistant wired into your systems, this is a small job. Three endpoints, a whitelist to read, and one number to carry between two of them. The hard part was making it safe to hand over, and that’s done.