/telnyx-email-curl

name: telnyx-email-curl
description: >-
  Send transactional email, batch sends, scheduled delivery, templates, email
  validation, and track delivery events. Use for notifications, alerts, and
  automated email workflows.
metadata:
  author: telnyx
  product: email
  language: curl

Telnyx Email - curl

Installation

# curl is pre-installed on macOS, Linux, and Windows 10+
# jq is required for examples that capture IDs from responses:
#   macOS: brew install jq
#   Debian/Ubuntu: sudo apt-get install jq

Setup

export TELNYX_API_KEY="YOUR_API_KEY_HERE"

All examples below use `$TELNYX_API_KEY` for authentication.

Error Handling

All API calls can fail with network errors, rate limits (429), validation errors (400 or 422), or authentication errors (401). Preserve the response body so the Telnyx error code and detail remain available:

curl --fail-with-body \
  -X POST \
  -H "Authorization: Bearer $TELNYX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": {"email": "sender@example.com", "name": "Example"},
    "to": ["recipient@example.net"],
    "subject": "Hello from Telnyx",
    "text_body": "Your notification is ready."
  }' \
  "https://api.telnyx.com/v2/email_messages"

Common errors: `401` invalid credentials, `403` sender-domain eligibility or verification failure, `404` resource not found, `413` body larger than 8,000,000 bytes, and `422` semantic validation or template-rendering failure. A `429` is not necessarily a transient throughput limit: it can indicate a reputation suspension or a daily policy limit. Inspect `.errors[0].code` and `.errors[0].detail` before deciding whether to retry. See the full taxonomy in [references/api-details.md](references/api-details.md#error-code-taxonomy).

Important Notes

• **Base URL:** All paths in this skill are relative to `https://api.telnyx.com/v2`.
• **Sender domain:** The domain in `from.email` must be authorized and ready for sending. A successful create response means accepted, queued, scheduled, or sandbox-created—not delivered.
• **Address input:** `from`, `reply_to`, and each `to`/`cc`/`bcc` item accept either a string address or `{ "email": "...", "name": "..." }`. Recipients must be unique across `to`, `cc`, and `bcc` after case-insensitive normalization.
• **Body or template:** `subject` is required unless `template_id` is supplied. With `template_id`, do not also send `subject`, `html_body`, or `text_body`; pass Liquid values in `template_variables`.
• **Pagination:** Core Email endpoints use `page_size` (default 25, maximum 100) and the opaque `page_cursor` returned in `.meta.page_cursor`. Do not translate these names to `page[size]` or `page[cursor]`.
• **Message listing:** `GET /email_messages` currently implements cursor pagination only; no message filters are exposed. Event and recipient list endpoints have their own filters.

Operational Caveats

• **Scheduling is fail-open:** `scheduled_at` is the preferred field. If it is invalid or in the past, the API silently sends immediately. Validate the timestamp before sending and confirm the response status is `scheduled` when future delivery is required. The legacy `send_at` alias remains accepted; if both are present, `scheduled_at` wins.
• **Batch status:** `POST /email_messages/batch` always returns `207 Multi-Status`, including when every item succeeds. It does not return 202.
• **Batch limit:** A batch contains 1–50 messages. Split larger jobs and give each request its own idempotency key.
• **Idempotency is endpoint-specific:** `Idempotency-Key` is supported only on `POST /email_messages`, `POST /email_messages/batch`, `POST /email_templates`, `POST /email_validations`, and `POST /email_validations/batch`. Do not send it universally.
• **Sandbox behavior:** `sandbox_mode: true` skips Kafka/MTA delivery, but still persists the message, emits a sandbox event, and creates a non-billable Email Detail Record (EDR). Batch-level `sandbox_mode` overrides every per-message value.
• **429 requires classification:** It can mean reputation suspension or a daily policy limit. Read the error code/detail; do not blindly back off and retry an account-policy failure.
• **Attachments are in-band JSON:** Put attachment content in the request as a Base64 string. `disposition: "inline"` plus `content_id` supports CID references. The whole request body is limited to 8,000,000 bytes (approximately 8 MB), including Base64 overhead.
• **Tags are not labels:** Outbound `tags` are immutable billing/reporting attribution propagated to EDRs and Mission Control. Mailbox `labels` are mutable workflow state and are a different concept.
• **Threading is single-send only:** `in_reply_to_message_id`, `reply_to_all`, and `forward_of_message_id` are accepted by single send but not by batch send. `in_reply_to_message_id` and `forward_of_message_id` are mutually exclusive.

Reference Use Rules

Do not invent Telnyx parameters, enums, response fields, or webhook fields.

• If a parameter, enum, or response field is not shown inline, read [references/api-details.md](references/api-details.md) before writing the request or handler.
• Before using an operation in `## Additional Operations`, read [the parameter reference](references/api-details.md#operation-parameters) and [the response schemas](references/api-details.md#response-schemas).
• Before matching webhook fields or event names, read [the webhook payload reference](references/api-details.md#webhook-payload-fields). Pollable and subscribable event enums are intentionally different.
• Treat the two delete-message routes marked **not yet available** as unreachable even though they appear in the OpenAPI contract.

Core Tasks

Send an email

Primary outbound transactional-email flow.

`POST /v2/email_messages`

| Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `from` | string or email-address object | Yes | Sender address; ob