Send transactional email through hosted Plunk

Use the client/SDK examples linked from Plunk’s current API reference. Its hosted base URL and API generation can differ from older Plunk tutorials, so keep the client and endpoint contract together.

Build a simple transactional send

This illustrates the documented direct-send body, not an executable HTTP request. Replace the recipient with an approved controlled address before using it through the documented client:

{
  "to": "recipient@example.net",
  "subject": "Plunk controlled test",
  "body": "<p>A message from the approved hosted project.</p>"
}

Authenticate using the server-side secret key and the verified project/domain configuration. A public pk_ tracking key does not authorize /v1/send.

Inspect acceptance and later delivery

Persist your application send intent, inspect the wrapped public API success/error result, and retain returned identifiers. Dashboard resource responses can use a different envelope, so do not apply one parser to every Plunk endpoint blindly.

Check Activity and the controlled recipient. Scheduled/throttled delivery options change when or whether a send occurs; use them only according to the transactional email contract, not as generic retry deduplication.

For uncertain outcomes, investigate activity before replaying. A MailKite fallback would be another real send with separate verification and identifiers, not an atomic continuation of the Plunk request.