Paced Email

Paced Email creates inbox aliases that batch incoming mail into daily, weekly or monthly digests. Agents list accounts and custom domains, create and delete alias inboxes, and check how much mail is waiting for the next digest.

7 actions API key available

Paced Email website Platform Documentation Capability data verified 2026-08-19

A new vendor or tool is approved for the team

Agent reads the vendor name, the owning team, and the requested digest cadence

List Inboxes confirms no alias already exists for that vendor

List Domains resolves whether the alias belongs on a company domain or on the shared one

Create Inbox opens the alias with the agreed cadence and the first message delivered straight through

The alias address goes back to the requester and onto the vendor record

The owning manager approves before an alias is retired, because deletion is the only way to stop one

What This Integration Enables

Paced Email is not a sending platform, and reading it as one misses the point. It creates alias inboxes that hold incoming mail and deliver it as a digest on a cadence you pick, with the option to let the very first inbound message through immediately so signup confirmations still work. Give every vendor, tool, and newsletter its own alias and two useful things become true at once: interruption drops to a schedule, and the provenance of any message stops being a matter of opinion. If mail arrives at the alias you only ever gave to one supplier, you know exactly who shared it.

FlowRunner agents make that pattern operational rather than personal. They read the accounts and custom domains available, create an alias as part of tool onboarding, list inboxes to see how much mail each is holding and when its next digest is due, and retire an alias when the relationship ends. The action surface is small on purpose, and one absence in it shapes every workflow: there is no update operation, so an existing alias cannot be paused, re-pointed, or re-scheduled through the API. The only lever on a live alias is deletion, which is precisely the kind of asymmetry FlowRunner's human-in-the-loop design exists to sit in front of.

Without FlowRunner

One address, every sender Vendor mail, alerts, and newsletters land in the same inbox and none of them can be traced to who signed up

Interruption as the default Low value mail arrives one message at a time all day, and each arrival costs attention

Unsubscribing one vendor at a time Cutting off a retired tool means finding its unsubscribe link, if it has one that works

With FlowRunner

One alias per vendor Every signup gets its own address, so the source of any message is a fact rather than a guess

Mail batched into a digest Traffic arrives daily, weekly, or monthly on a schedule the team chose

A single lever per relationship Retiring a vendor means retiring its alias, and the decision is recorded where the vendor record lives

Use Case Scenarios

An alias issued with every approved tool

A software request is approved in Airtable or as a ticket in Linear. The agent checks List Inboxes to make sure the vendor does not already have an alias, resolves whether it belongs on a company domain with List Domains, and calls Create Inbox with the vendor name as the local part of the address, a weekly digest, and the first message set to pass through so the account confirmation actually arrives. It writes the alias back onto the vendor record and posts it to the requester in Slack. The address the vendor receives was created for that vendor and for nobody else.
Noticing the day a vendor changed its habits

On a schedule, the agent pages through List Inboxes for the account and records each alias with how many messages are waiting for its next digest and when that digest is due. Because the API allows ten requests a minute across every endpoint, the sweep pages the list rather than looping a call per inbox, which is a design constraint worth building around rather than fighting. The agent compares this week's waiting counts against last week's and posts the movers: the alias that went from three messages a week to forty is the vendor that started running a campaign, and the team learns it before anyone starts filing.
Offboarding that closes the door properly

A tool is marked retired in the asset register. The agent gathers the evidence a person would otherwise assemble by hand: Get Inbox for the alias's current waiting count, next due date, and description, plus what the register says the tool was for and who owned it. It posts that package, waits, and only calls Delete Inbox once the owner has answered. A contract renewal notice sitting in an undelivered digest is exactly the kind of message this step exists to protect.

Human-in-Loop Highlight

Delete Inbox is the only lever this connector offers on a live alias. There is no update operation, so an alias cannot be paused, re-pointed at a different recipient, or moved to a slower cadence after it exists, which means every "make this stop" request resolves to a deletion. That deletion takes the mail already waiting for the next digest with it, and the address itself stops accepting mail, so anything still signed up to it starts bouncing where nobody is watching. So the offboarding agent does the gathering and stops at the door. It posts to the alias owner: "Alias vendorname@ is holding six messages, next digest due Friday. The register says this tool was retired last month and billing was on the corporate card. Deleting it discards those six messages and the address will bounce from then on. Delete, or hold it one more cycle?" The agent can prove what is waiting. Whether the last six messages matter is a judgment about the relationship, and it belongs to the person who owns it.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

7 actions

Account and Domains

Get Current User Reads the user the access token belongs to. The cheapest confirmation that a token works, and the natural first call because everything else hangs off an account that user owns.
List Accounts Lists the accounts the token can reach with their name, plan, and whether the subscription is active. Every inbox operation needs an account identifier from here, because the token alone does not imply one.
List Domains Lists the custom domains on the account. A domain identifier from here is what puts an alias on a company domain rather than the shared one.

Alias Inboxes

List Inboxes Lists an account's inboxes, each with its alias address, digest frequency, how many messages are waiting for the next digest, when that digest is due, and whether it is paused. The read behind every sweep and audit on this connector.
Get Inbox Reads one inbox in detail. The account identifier is required here as well, and an inbox belonging to another account answers as missing rather than as forbidden.
Create Inbox Creates an alias that batches incoming mail into a digest, with the cadence, digest format, recipients, and description set at creation. The name is the local part of the address rather than a label, and the option to deliver the very first inbound message immediately is what keeps signup confirmations usable.
Delete Inbox Deletes an alias. Mail already waiting for the next digest goes with it and the address stops accepting mail, which is why this operation sits behind the human gate above.

Frequently Asked Questions

What can FlowRunner do with Paced Email?

FlowRunner agents can run Get Current User, List Accounts, and List Domains in Paced Email, plus 4 more actions.

Does connecting Paced Email to FlowRunner require OAuth?

No. Paced Email connects to FlowRunner with an API key, no OAuth flow required.

Can Paced Email trigger a FlowRunner workflow automatically?

Paced Email doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Paced Email

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us