Telnyx Email 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.

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 before writing the request or handler.
• Before using an operation in ## Additional Operations, read the parameter reference and the response schemas.
• Before matching webhook fields or event names, read the webhook payload reference. 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

curl --fail-with-body \
  -X POST \
  -H "Authorization: Bearer $TELNYX_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 8e03978e-40d5-43e8-bc93-6894a57f9326" \
  -d '{
    "from": {"email": "orders@example.com", "name": "Example Orders"},
    "to": [{"email": "customer@example.net", "name": "Customer"}],
    "subject": "Order received",
    "html_body": "<p>Thanks for your order.</p>",
    "text_body": "Thanks for your order.",
    "tags": ["order-confirmation"],
    "tracking_settings": {"open_tracking": true, "click_tracking": true}
  }' \
  "https://api.telnyx.com/v2/email_messages"

Primary response fields:

• .data.id, .data.status, .data.from, .data.to, .data.cc, .data.bcc
• .data.subject, .data.template_id, .data.attachments, .data.events
• .data.created_at, optional .data.scheduled_at, .data.sandbox, and .data.recipient_statuses
• optional top-level .suppressed[] when some recipients were removed but at least one remains

Send a batch

Send 1–50 independent messages. Always parse both success and error arrays from the 207 response.

POST /v2/email_messages/batch

curl --fail-with-body \
  -X POST \
  -H "Authorization: Bearer $TELNYX_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: d6aa99f9-df20-4caf-99aa-e4c8b67e80ef" \
  -d '{
    "messages": [
      {
        "from": "alerts@example.com",
        "to": ["one@example.net"],
        "subject": "Alert one",
        "text_body": "First alert"
      },
      {
        "from": "alerts@example.com",
        "to": ["two@example.net"],
        "subject": "Alert two",
        "text_body": "Second alert"
      }
    ]
  }' \
  "https://api.telnyx.com/v2/email_messages/batch"

Primary response fields:

• .data[] — successful EmailMessage objects
• .errors[] — failed items with zero-based index, code, and message
• .meta.total, .meta.succeeded, .meta.failed

Schedule and cancel an email

Scheduling uses the normal create endpoint. Confirm .data.status == "scheduled"; an invalid or past timestamp is silently treated as an immediate send.

# Schedule for a future time (compute dynamically so the value is always in the future)
SCHEDULED_AT=$(date -u -v+1H '+%Y-%m-%dT%H:%M:%SZ' 2>/dev/null || date -u -d '+1 hour' '+%Y-%m-%dT%H:%M:%SZ')

# Capture the scheduled message ID for cancellation below
EMAIL_ID=$(curl -s --fail-with-body \
  -X POST \
  -H "Authorization: Bearer $TELNYX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "reminders@example.com",
    "to": ["customer@example.net"],
    "subject": "Appointment reminder",
    "text_body": "Your appointment is tomorrow.",
    "scheduled_at": "'$SCHEDULED_AT'"
  }' \
  "https://api.telnyx.com/v2/email_messages" | jq -r '.data.id')

Cancel only while the message is still scheduled:

DELETE /v2/email_messages/{email_id}/schedule

curl --fail-with-body \
  -X DELETE \
  -H "Authorization: Bearer $TELNYX_API_KEY" \
  "https://api.telnyx.com/v2/email_messages/$EMAIL_ID/schedule"

The cancel response is an EmailMessageResponse whose .data.status is cancelled.

List and retrieve messages

GET /v2/email_messages uses newest-first cursor pagination and has no filters. GET /v2/email_messages/{id} returns the detail shape, including bodies.

curl --get --fail-with-body \
  -H "Authorization: Bearer $TELNYX_API_KEY" \
  --data-urlencode "page_size=25" \
  --data-urlencode "page_cursor=$PAGE_CURSOR" \
  "https://api.telnyx.com/v2/email_messages"

curl --fail-with-body \
  -H "Authorization: Bearer $TELNYX_API_KEY" \
  "https://api.telnyx.com/v2/email_messages/$EMAIL_ID"

The detail response adds .data.text_body and .data.html_body. Continue pagination only when .meta.page_cursor is present.