Outbound API and SMTP

Choose the right sending operation

• Transactional message: POST /v1/send with a secret project key.
• Batch: POST /emails/batch; inspect individual results rather than assuming the whole batch succeeded.
• Campaign: create a draft through /campaigns, review the audience and content, then send or schedule it.
• Automation: configure a workflow; an API accepting its configuration does not prove that every future branch will execute.

The complete API catalog lists sending, campaign, workflow, template, domain, activity, analytics, suppression, and warm-up operations. Its request fields are generated from the backend validators.

curl https://api.sendbound.com/v1/send \
  -H "Authorization: Bearer $SENDBOUND_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: application-message-unique-id" \
  -d '{"from":"sender@your-verified-domain.example","to":"recipient@example.com","subject":"Hello","body":"<p>Hello</p>","text":"Hello"}'

Use body for HTML and text for plain text. A saved template can supply content; follow the generated send schema for its associated data and required fields. Outbound attachments use Base64 content, not publicly accessible URLs. The send and batch endpoints accept at most 30 MiB of JSON total; Base64 expands files, and the sender also enforces per-message attachment and recipient limits. A batch cannot exceed the request limit just because each individual message is small.

Acceptance, delivery, and retries

A successful API/SMTP response confirms acceptance into the sending pipeline, not inbox placement. Read email status or subscribe to email.sent, email.bounced, and email.complained webhooks. Opens and clicks are tracked events, not reliable proof that a person read a message.

Reuse the same idempotency key when checking an uncertain submission. A duplicate key produces 409, not a replay of the original response. Reconcile using your own message record and email status before retrying. Do not switch transport or blindly retry after a timeout: the first transport might already have accepted it.

For API rate limits, honor Retry-After. Keep permanent validation/authentication failures separate from temporary server failures. Confirm the sender domain is verified and the project has sending allowance before trying again.

SMTP

Open Developer → SMTP in the dashboard for the deployment's advertised host, port, TLS mode, username, and password. The normal submission configuration uses port 587 with STARTTLS; use the dashboard's actual settings rather than assuming an inbound MX hostname is an SMTP submission host.

Keep SMTP credentials on your server. They do not belong in browser code, MCP tool arguments, screenshots, or source control. The dashboard's SMTP test checks the configured submission path; an independent external SMTP send and recipient check are still required to verify a live deployment.

Inbound receiving is a separate flow. See the inbound guide for receiving-domain MX records, routing, webhook signatures, retries, and private attachments.