Skip to main content

Transactional Emails

Details how developers can use AIQ's public API to send transactional emails to their customers.

⚠️ Important: This endpoint is not intended for sending marketing messages. Stores should only use it for transactional content (receipts, order status, etc.), both for compliance and because spam reports against it can opt the contact out.

This endpoint allows you to send transactional emails. These are usually one-off notifications used in order and delivery processes.

  • "Your order has been processed"

  • "Your order is ready for pickup"

  • "Please verify yourself with pin code: 1234" etc.

Endpoint reference

Authentication

  • Header: X-APIKEY: <your API key> (required). The key is found in the dashboard under Settings → API & Tracking.

  • A missing/invalid key returns 403 with "Please provide a valid API key".

Rate limits

Rate limits are enforced per API key

Window

Limit

Per second

750

Per minute

10,000

Per hour

200,000

Every response includes X-Rate-Limit-Limit and X-Rate-Limit-Remaining (formatted second|minute|hour). When exceeded, you get 429 with X-Rate-Limit-Reset and Retry-After headers (seconds).

Request body

{
"email": "[email protected]",
"subject": "Your order is ready",
"body": "<h1>Your order is ready</h1><p>Your order <strong>#19400</strong> is ready for pickup.</p>"
}

Field

Type

Required

Notes

email

string

Yes

Recipient address. Must be a syntactically valid email (RFC 5322 parseable). It is normalized to lowercase, and fake addresses are rejected (e.g. test@, fake@, noemail@, 123@, all-zero prefixes, blacklisted domains). Common typos like .con/.come are auto-corrected to .com.

subject

string

Yes

Whitespace-trimmed; must be non-empty.

body

string

Yes

HTML content of the message. Whitespace-trimmed; must be non-empty. The same content is used as the plain-text/preheader part.

Sender ("from" address) behavior

The caller does not control the from address — it's resolved server-side:

  1. If the account has exactly one authenticated email domain (DNS-validated in Settings → Email) with a verified sender, that sender's from-email and from-name are used.

  2. Otherwise (no domain configured, or domain not yet validated/verified), the email is sent from the platform's default sender address.

So configuring and validating a sending domain is strongly recommended for deliverability, but it is not required to call the endpoint, and the recipient address never needs to match any domain setup.

Miscellaneous Details

  • Unsubscribe headers: List-Unsubscribe / List-Unsubscribe-Post (one-click) headers are automatically added, pointing to the platform's email unsubscribe endpoint for that recipient.

  • Message logging: each send is recorded in the contact's message history/timeline (campaign ID "other"), so it appears in the dashboard messaging views.

  • No opt-out gate: the handler does not check the recipient's marketing opt-in status — these are treated as transactional.

Response Statuses

Status

Meaning

200

Sent. Body: {"status": 200, "data": "OK"}-style OK response.

400

Malformed JSON, "invalid email address", "missing email subject", or "missing email body".

403

Missing/invalid X-APIKEY.

429

Rate limit exceeded (see Retry-After).

500

Account not found/inactive, or the downstream send to the email provider failed ("sending email: ...").

503

"service is temporarily unavailable" — backend messaging dependency temporarily down; safe to retry.

Example Payload

curl -X POST "https://lab.alpineiq.com/api/v2/email" \
-H "X-APIKEY: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"email": "[email protected]",
"subject": "Your order is ready",
"body": "<h1>Your order is ready</h1><p>Order <strong>#19400</strong> is ready for pickup.</p>"
}'

Example Successful Response

{
"data": "OK",
"code": 200,
"success": true
}
Did this answer your question?