Smartlead
Sending and reply handling
A cold email platform. It manages sending mailboxes and their warmup, runs multi step sequences, and pushes replies out to other systems over webhooks.
Smartlead is the sending platform I have used where a client already ran on it, or where the reply side mattered more than the push side. The sending job is the same as any other tool in this category. What made it interesting to me was that its webhooks are good enough to build on top of.
How I use it
Mailboxes first, campaigns second. Domains, mailboxes, warmup and daily limits get set up and left alone to settle before any real list goes near them. The sequence is the easy part. The sending reputation underneath it is the part that takes weeks and cannot be rushed at the end.
The reply webhook is the useful surface. A reply event carries the lead, the campaign and the message body, which is enough to trigger real work outside the platform. I built a reply assistant on that: the webhook fires, a small pipeline pulls out the thread, a model drafts a suggested response, and the draft is stored against the lead so a person sees it next to the reply instead of in another tab.
Bulk operations, not loops. Leads go in a hundred at a time and mailbox pages come back a hundred at a time, so anything that touches the whole account is written as paged batches from the start. Writing it as a per record loop works on a test list and then falls over on a real one.
Rate limits are part of the design, not an error to retry. The API is deliberately slow to accept calls, so a script that walks a whole workspace needs a deliberate pace built in. I would rather a job take longer and finish than run fast and half fail.
What I have learned the hard way
The API key travels in the query string. That means it lands in shell history, in any log that records full URLs, and in a copy pasted command. It needs the same care as a header credential and gets less of it by default, because a URL does not look like a secret.
A webhook you cannot replay is a webhook you cannot debug. The event arrives once. If the receiving end is down or throws, the information is gone, and you find out later from the absence of a record rather than from an error. Anything I hang off a reply event now writes the raw payload down before it does anything clever with it.
Warmup numbers describe the mailbox, not the campaign. A healthy warmup panel says the mailbox is exchanging mail with other warmup mailboxes. It says nothing about whether real recipients want the campaign, and it is easy to read the green as a verdict on the copy.
Sending platforms are the least portable part of a stack. Sequences, variable names and mailbox setup all have to be rebuilt by hand to move, and the reply history does not come with you at all. That is worth knowing before a migration is agreed, not during one.
Resources
This is one part of a stack. The rest is on the tools page, and what I build with it is on work.