Email and SMS campaigns: Unisender, SendPulse, Mailchimp, website integration

Triggered email 10 minutes after registration converts 4–5x better than the same email 24 hours later. This is not a marketing myth — it's mechanics: while user is warm, while they remember context. But most integrations with mailing services are built like this: form submits → synchronous HTTP request to API → if API is slow, user waits 3 seconds → email goes or doesn't, nobody knows.

Providers and their API

Unisender — Russian provider, popular in SMB segment. REST API, simple. Adding contact: importContacts, sending transactional email: sendEmail. Important: for transactional emails (order confirmation, password reset) Unisender Go — separate service with different API and separate price. Mixing bulk campaigns and transactional in one stream — bad idea for domain reputation.

SendPulse — provides email, SMS, web push, Viber, Telegram bots via single API. For projects needing omnichannel, convenient. Automation 360 — visual chain builder, can start automation via API event. SDK for PHP (sendpulse/rest-api-php-sdk) supported, but updated irregularly — better to use directly via Guzzle.

Mailchimp — choice for international audience and marketing teams accustomed to Mailchimp ecosystem. Transactional email — via Mandrill (subsidiary service). Marketing API v3 for managing lists, tags, campaigns. Webhook for events: open, click, unsubscribe, bounce.

SMS. For Russia: SMSC, MTS Exolve, Devino Telecom, SMS Aero. API for all similar: method send, parameters phone, message, sender (sender name — needs separate registration with operator). One nuance: sender name must be registered via aggregator with contract — without this SMS won't send on MTS/MegaFon/Beeline networks.

How to build integration correctly

Transactional and marketing — always separate. Transactional emails (order confirmation, password reset, delivery status) — via separate sender domain or subdomain tx.example.com. Marketing campaigns — via mail.example.com or news.example.com. If marketing campaign gets many spam complaints, shouldn't affect transactional stream reputation.

Queue and retry. Any call to email API — via queue (Laravel Queue, Bull, Celery). If Unisender returns 503 — task goes to retry in 5 minutes, then 15, then 60. After 5 failed attempts — to dead letter queue with alert. User already got their 200 OK and doesn't know about problem.

Templates. Store templates in code (Blade, Twig, React Email), not in provider's interface. Reasons: versioning via Git, preview in browser without sending, testing capability. For complex templates with dynamic content — react-email with export to HTML via @react-email/render.

Validation and GDPR/152-law. Before adding contact to list — double opt-in (confirmation email). Store confirmation fact with timestamp in own DB. On unsubscribe — unsubscribe both at provider and in own base. Ignoring webhook unsubscribe — direct path to account blocking at provider.

Deliverability monitoring. Connect webhook from provider on events bounce (hard and soft), spam_complaint, unsubscribe. Hard bounce — immediately mark email as invalid in own DB, no more sending. Soft bounce 3 times in a row — same. Metrics: open rate, click rate, bounce rate, unsubscribe rate — check at least once a week.

Process and timelines

Audit current communication flows → provider selection for transactional and marketing traffic → DNS setup (SPF, DKIM, DMARC) → template development → backend integration → queue and monitoring setup → testing all trigger scenarios.

Cost calculated individually.