Send approved agent messages with SendHog

Treat the model’s output as a proposal, not a request the provider must send immediately. Store drafts and approval state in your application. This guide does not assume a provider-side draft or reply-thread API that SendHog has not documented.

Define the approved operation

Before submission, show the operator the actual From identity, every recipient, subject, complete content, and any sensitive context included. Bind approval to a proposal revision and use a transactional claim so only one worker can submit it. Editing the proposal invalidates its previous approval.

Use an authenticated sender on the configured domain and an email.send key kept only by the sending worker. The reader’s key and webhook-management key should not be exposed to the model as substitutes.

Use the native SDK

Install @sendhog/sdk using the current installation guide. This is a sending-worker excerpt: approved is your application-owned, immutable approved record. Calling it sends real mail:

import { SendHog } from "@sendhog/sdk";
if (!process.env.SENDHOG_SEND_KEY) throw new Error("Missing sending credential");
const client = new SendHog(process.env.SENDHOG_SEND_KEY);
const result = await client.send({
  from: approved.from,
  to: approved.to,
  subject: approved.subject,
  text: approved.text,
});
// Persist result.id against the claimed operation before processing feedback.

Keep conversation correlation in your application. Do not promise that adding Re: establishes a native thread or that compatibility clients support every original provider’s options. Use only fields the current SendHog contract supports.

Handle acceptance and uncertainty

SendHog’s event documentation says sending waits for provider acceptance and records that acceptance before returning. This is not final inbox delivery. Correlate delivery/bounce/complaint events without allowing late events to clear a suppression.

If the provider outcome is ambiguous, SendHog reports SendOutcomeUnknown. Mark the operation for investigation and inspect message activity or contact support before resending. Do not invent an idempotency guarantee or fail over to another ESP automatically.

Test approval changes, concurrent claim attempts, duplicate incoming events, and the uncertain-outcome path without executing live sends. Then authorize one controlled message if an operator wants end-to-end delivery evidence.