Elaine transactional messaging interfaces connect operational systems with personalized message delivery. They support individual real-time requests as well as asynchronous, high-throughput submission patterns.
When to use transactional messaging
- Order, booking, account, service, or security notifications.
- Messages triggered by a customer or system event.
- Personalized content assembled from a centrally managed message template and transaction data.
- Applications that need a technical acknowledgement and later delivery status.
Submission patterns
| Pattern | Use it for | Important consideration |
|---|---|---|
| Individual API submission | Low-latency submission of one transaction at a time | The response confirms technical acceptance, not final delivery. |
| Bulk or parallel submission | Higher request rates where supported by the selected endpoint and capacity tier | Control concurrency, preserve correlation identifiers, and handle partial failures. |
| Asynchronous high-throughput submission | Large message volumes without coupling the source application to message processing time | Use queue-aware monitoring and query or receive the resulting message status separately. |
Message lifecycle
- The source application submits recipient, template, personalization, and control data.
- Elaine validates and accepts or rejects the request.
- The message is personalized, rendered, and placed into the delivery process.
- The integration correlates the request with queued, sent, bounced, or failed status information.
Send a transactional message with cURL
The functional HTTP API exposes api_sendSingleTransaction(array $data, int $nl_id, int $ev_id, int $variant_position, bool|int $blacklist). Replace the environment variables and IDs in this example, then copy the complete command:
export ELAINE_BASE_URL="https://your-elaine-domain.example"
export ELAINE_JWT="replace-with-an-elaine-issued-jwt"
curl --get "$ELAINE_BASE_URL/http/api/api_sendSingleTransaction" \
--header "Authorization: Bearer $ELAINE_JWT" \
--data-urlencode 'json=[{"content":{"c_email":"recipient@example.com","t_order_number":"A-12345","t_total":"49.90"}},123,456,null,true]' \
--data-urlencode 'response=json'
In the example, 123 is the transactional message ID and 456 is the optional recipient-group ID. Temporary transaction values use the configured t_ fields. The successful function result is the queue ID; use it to correlate the request with later message status.
Security note: Keep blacklist evaluation enabled unless an explicitly reviewed transactional use case permits different behavior. Never place a production JWT in source code or documentation.
Design for throughput
For workloads ranging from single real-time messages to millions of messages per hour, select the appropriate submission mode and contracted capacity. Keep payloads focused, reuse managed templates, avoid unnecessary synchronous dependencies, and apply controlled concurrency or asynchronous processing.
Capacity note: Message throughput depends on rendering and personalization complexity, payload and attachment size, channel and deliverability controls, queue configuration, and contracted capacity. Validate peak-volume scenarios before launch.
Reliability requirements
- Assign a stable external correlation identifier to every transaction.
- Design retries so that a repeated request does not unintentionally create duplicate messages.
- Distinguish request acceptance from message delivery.
- Monitor queue state, delivery state, rejects, bounces, and timeouts.
- Define a fallback process for prolonged unavailability.