Send a Loops transactional template from an application

Use the official SDK linked from Loops documentation and its current transactional send method. The transactional guide defines a two-step model: author the email, then trigger it through the API.

Bind a real template to one operation

This illustrates the request shape, not a runnable send. Use a published/active transactional ID and approved recipient in the actual client call:

{
  "transactionalId": "your-transactional-email-id",
  "email": "recipient@example.net",
  "dataVariables": { "name": "Test reader", "resetUrl": "https://your-app.example/test-only" },
  "addToAudience": false
}

Only supply variables declared/expected by the selected template. Never use a real user’s secret reset link in a shared test payload. Protect the API credential in backend configuration.

Verify template behavior and outcome

Persist the application operation before the send. Inspect the result, provider activity, and controlled recipient; use available delivery/bounce feedback for asynchronous outcomes.

Test required-variable validation and a deliberately safe template version before production. Do not use an open/click event as evidence of a successful transactional delivery—Loops documents that transactional email does not track those signals.

Treat uncertain timeouts carefully and avoid replaying a password-reset operation blindly. A change to MailKite requires an explicitly migrated template/variable contract; copying a Loops transactional ID into a MailKite request cannot identify a template there.