The first thing most developers do when they need an automated email is open the REST reference and look for a send method. There isn't one. That single missing method sends people down two wrong paths — building a scenario in an external platform for what a workflow could do in one block, or assuming the built-in action is broken when it quietly refuses to fire. Both are avoidable once you know where the send actually happens.

Is there a REST API method to send an email?

No. In Bitrix24 (Alaio) the mailservice.* family manages mail services — create, update, list, delete — and the Webmail methods manage mailboxes, messages and recipients. Nothing in that set puts a message on the wire. Connecting a mailbox and sending are interface operations, not API ones.

crm.activity.add is the method people find next and misread. It writes an outgoing email activity onto the timeline, which is bookkeeping: the record appears in the client's card whether or not anything reached an inbox. Treat it as a log entry, not as a send.

So there are exactly two honest ways to email a client from automation: the built-in action inside a workflow, or an HTTP call to a provider that does the sending for you. Everything below is one of those two.

How do you send an email from a workflow?

The built-in action is Send email to customer, available to both automation rules and business processes. It needs four things: a sender address (a specific mailbox, or auto-select, which sends from the responsible employee's address), the recipient address type — work, home, newsletters or auto-select — a subject, and a body with field values placed into it.

Three conditions decide whether it runs at all, and none of them raises an error you would notice:

The responsible employee must have a mailbox connected. No mailbox, nothing to send from. The address type in the setting must match what the card actually holds — pick "work" when only "newsletters" is filled in and the email never leaves. And when several contacts hang off a deal, only the first one gets it, with the contact taking priority over the company.

That is the whole failure list for the happy path, and it explains most "the automation is broken" tickets. Which channel suits which event is covered in notifications from a business process; when the rule doesn't run at all, start with automation not running.

What about SMS?

Same shape, one extra requirement: the portal doesn't send text messages itself. It hands them to a provider app installed from the Market, which talks to the carrier. Without a connected provider the action sits in the list and does nothing. Message length is capped, so long texts are either truncated or billed as several.

The phone type has to match the card the same way the email type does — choose "work" when only a mobile number is stored and the message is dropped. Normalise the number first with Format phone with prefix: to a carrier API, 020 7946 0958 and +44 20 7946 0958 are different strings, and one of them will not deliver.

How do you send through your own provider?

When the built-in channels run out — a transactional email service, a cheaper SMS aggregator, WhatsApp, Telegram — the send becomes an outbound HTTP call from inside the workflow. This is also the answer to the missing REST method: you don't send through Bitrix24, you send past it.

The HTTP request robot calls the provider's API and returns the status code and the body, so the next step can branch on the result: 200 means write "sent" into the card, anything else means raise a task for a human. Build the payload with Build JSON instead of gluing braces together by hand, and run query-string values through URL encode — the first address containing a plus sign will otherwise break the call.

For messages you cannot afford to lose, use Reliable webhook: it retries on network failures and 5xx responses with growing pauses rather than dropping the workflow at the first bad second. The difference only shows at volume — a five-minute maintenance window on the provider's side costs you every message in it. The mechanics of calls in both directions are in the webhooks guide, and the wider picture in workflow automation in Bitrix24.

Why don't the emails arrive?

Cloud portals carry a daily cap on outgoing mail — a thousand messages a day by default. A campaign larger than the cap isn't cancelled: the first thousand go out and the rest wait until tomorrow. The cap moves: it rises while recipients don't complain and falls when they do, and heavy spam reporting can block sending outright. The share of that allowance spent on campaigns rather than on CRM and mailbox correspondence is a setting you control.

Three consequences worth acting on. Don't put revenue-critical mail — invoices, credentials, order confirmations — on the portal's own reputation; send those through a service where you own the domain. Clean the list before sending, not after: invalid addresses produce bounces, and bounces pull the cap down. And keep unsubscribing genuinely one click, because a spam complaint costs more than a lost subscriber.

What to fix in the list before you send

List quality decides more than copy does. Drop cards with no address using Field is not empty — they will not receive anything anyway and only distort your stats. Merge duplicates first: three identical emails to one person is the fastest route to a complaint. Get the salutation right automatically with Gender by name, explained in gender by name. General data hygiene is covered in CRM data cleanup.

To fix an existing base in one pass, use bulk workflow launch: one template — check the address, normalise the phone, set a flag — fired across every contact.

What next

Start with a single triggered email: event, condition, send, write the fact of sending back into the card. Once it has survived a week without surprises, add SMS to the same scenario, and only then move to bulk sending, where one mistake is multiplied by the size of your list. The rest of the blocks live in the robot catalog: conditions, HTTP calls, string and date tools. And if the one you need is missing — describe the task: Roboteka builds missing activities for free and ships them to the shared library.