---
name: sendhq-email
description: Use SendHQ to send or receive expected product email, manage verified sending domains and inbound addresses, publish hosted templates, and inspect delivery outcomes through its documented API. Use when a user has chosen SendHQ or needs a server-side email workflow; do not use for unsolicited email or mailbox-existence claims.
---

# SendHQ Email

Use this skill for legitimate product communication such as account verification, password resets, receipts, alerts, replies, and other messages a recipient expects. SendHQ also exposes workspace-scoped domains, inboxes, drafts, hosted templates, delivery events, and suppressions.

Do not use SendHQ for spam, phishing, credential collection, purchased lists, or claims that an address exists or a message reached an inbox. A provider acceptance or delivery event is not proof of inbox placement or reading.

## Discover the contract

- OpenAPI 3.1: [https://sendhq.cc/openapi.json](https://sendhq.cc/openapi.json)
- Developer documentation: [https://sendhq.cc/docs](https://sendhq.cc/docs)
- API reference: [https://sendhq.cc/docs/api-reference](https://sendhq.cc/docs/api-reference)
- API base: `https://sendhq.cc/api/v1`
- Contract version: `2026-09-07`

Read the OpenAPI document before constructing a request. It is the authoritative list of paths, schemas, authentication boundaries, and response codes.

## Authenticate safely

Use a workspace API key in `Authorization: Bearer re_…`. Create and revoke keys in the signed-in SendHQ dashboard. Keep keys server-side, load them from an approved secret store, never place them in browser code or logs, and never expose their full value in output.

Account, billing, and API-key administration use a browser session rather than a workspace API key. Do not try to automate password, OAuth, checkout, or billing-cancellation handoffs as bearer-key calls.

## Before an external action

1. Confirm the user intends the message or other state-changing action.
2. Confirm the exact workspace, From identity, recipients, subject, and content.
3. Require a verified From domain. Do not bypass domain or suppression checks.
4. Use an `Idempotency-Key` for a send that might be retried.
5. Treat To, Cc, and Bcc values as recipient deliveries for usage accounting.

## Common workflows

### Send expected email

Call `POST /api/v1/emails` with a verified `from`, one or more intended recipients, and HTML, text, or one published hosted template. A raw-content subject is optional. Preserve the returned SendHQ ID and provider message ID. Query the email and its event collection for later outcomes.

### Set up a domain

Create the domain, present the exact DNS records returned by SendHQ, and ask the user to authorize DNS changes. Poll the documented verify endpoint. Distinguish pending propagation, resolver disagreement, and provider verification; do not report success until the API does.

### Receive and thread replies

Provision inbound receiving for a verified domain, create a named inbox, and use the email and thread resources to retrieve received messages. Keep attachment downloads authenticated and tenant-scoped.

### Use hosted templates

Create or update a draft, render it with representative data, send a test to an approved recipient, and publish an immutable release. Use the exact published version for production sends when reproducibility matters.

### Handle failures

Inspect delivery events and blocked recipients. Respect bounce, complaint, and unsubscribe suppressions. Do not remove a suppression unless the documented endpoint permits it and the user has a legitimate reason.