Integrations
Integrations are the delivery channels VocaLoop sends fill links through. They're managed once per account on the Settings → Integrations tab (/settings/integrations, Settings in the sidebar) and used by every project.
| Channel | Provider | Setup guide |
|---|---|---|
| Meta WhatsApp Cloud API | WhatsApp integration guide | |
| Any SMTP server | This page (below) | |
| Text (SMS) | Twilio Programmable Messaging | Twilio SMS integration guide |
Channels: on/off and whose credentials
Every channel has two independent switches:
Enabled — whether the channel can send at all. WhatsApp is on by default; email and text are off until you enable them. At least one channel must stay enabled, and sends over a disabled channel fail with "channel is disabled".
Credentials — not every channel offers both sources yet:
WhatsApp and Email run on system credentials (the server's
env configuration:
WHATSAPP_*,SMTP_*in the root.env) with nothing to configure. Bringing your own credentials for these channels is coming soon.Text (SMS) runs on your own Twilio credentials only — saving a
config enables the channel in one step, and removing it switches the channel off (there are no system credentials to fall back to yet; system-managed SMS is coming soon).
Every provider call is counted per channel and per credential source (system vs your own) — the account Usage page shows the split, and system calls are what VocaLoop bills.
How secrets are handled
Your own configs are encrypted at rest with Fernet, keyed by
ENCRYPTION_KEYin the root.env(see Getting Started).After saving, secret fields (passwords, tokens) are shown masked (
••••abcd). When editing a card later, leave the masked value untouched to keep the stored secret — only paste a new value when rotating it.Removing your credentials deletes the stored config entirely and switches the channel off.
Testing a channel
Every enabled card has a test send: enter a recipient (your own email or phone) and VocaLoop sends a real message through the credentials currently in effect — system or your own. Provider errors are surfaced verbatim, so a wrong password or unverified number shows up immediately. Template-level test sends (from a project's Templates tab) resolve credentials the same way.
Email (SMTP) setup
The email card takes standard SMTP credentials:
| Field | Required | Notes |
|---|---|---|
| Host | yes | e.g. smtp.gmail.com, smtp.sendgrid.net, email-smtp.us-east-1.amazonaws.com |
| Port | yes | Default 587 (STARTTLS). 465 is implicit-TLS on most providers |
| Username | yes | SMTP login (often the full email address) |
| Password | yes | SMTP password — stored encrypted, masked after save |
| From email | yes | The sender address recipients see (must be allowed by your provider) |
| From name | no | Display name shown next to the address |
| Use TLS | yes (default on) | Leave on for port 587 |
Provider notes:
Gmail / Google Workspace — regular passwords won't work. Create an App password (Google Account → Security → 2-Step Verification → App passwords) and use it as the SMTP password with host
smtp.gmail.com, port587, username = your full address.SendGrid — username is literally
apikey; password is an API key with Mail Send permission; the From address must be a verified sender.Amazon SES — use SMTP credentials (not your AWS keys) from the SES console; verify the From domain/address first. New SES accounts start in sandbox mode and can only send to verified addresses.
If a test send fails, the SMTP server's error message is shown — the usual suspects are a wrong app password, an unverified From address, or the provider blocking the connection until "less secure app"/API access is enabled.