Knowledge base
Sending lanes
App mail and newsletters travel separately, so a newsletter never delays a password reset.
Details
- Mail leaves in two lanes. App mail carries password resets, receipts, codes and replies. Broadcasts carry newsletters and other mail to many people. Each lane has its own queue and its own reputation, so a large newsletter never holds up a sign-in code.
- Mail written in the app, replies and sends through the API travel as app mail, and every copy of a broadcast travels in the broadcast lane. A send through the API can choose the broadcast lane with stream, and over SMTP the header X-OpenEmail-Stream does the same.
- The Sent tab of Settings → Analytics shows both lanes under Sending lanes, with the recipients of the last 7 days and the bounce and complaint rates of each lane.
- The broadcast lane pauses itself when its bounce rate passes 4% or its complaint rate passes 0.2% over 7 days, once it has sent to at least 500 recipients. The workspace owner gets an email, broadcasts already going out are held, and new ones are refused until the lane is resumed. App mail is never paused.
- Only the workspace owner resumes it, with Resume broadcasts in the same panel. Held messages go out at once and the 7 day count starts again, so clean the audience first.
- The lanes are on the REST API as GET /sending/streams and POST /sending/streams/broadcast/resume, on the SDK as sending.listStreams and sending.resumeStream, on the command line, and on the MCP server as getSendingStreams and resumeSendingStream.