Three steps to a delivered message: create a key, verify a domain, make one call. This is the quickstart, not the reference. The full endpoint reference lives in the OpenAPI document the API serves, linked at the bottom.
In the dashboard, open API keys and create one. The key is shown once, at creation, and is stored only as a salted scrypt hash. Nobody, including us, can read it back afterwards. Keep it in your server environment as NOTIX_API_KEY and never ship it to a browser.
A key can be scoped to a single sending domain, so a service that only sends receipts cannot send from your marketing domain.
Open the dashboardAdd your domain and Notix generates the exact DNS records to publish: a DKIM record on a ._domainkey subdomain, an SPF record including amazonses.com, and a _dmarc record. Notix then verifies them and keeps re-checking, so a domain that drifts out of alignment tells you rather than silently landing in spam.
You can send from a subdomain of your main domain. Doing so keeps a bad campaign from damaging the reputation of the domain your invoices go out on.
One POST, one JSON body, one message id back. Attachments, scheduling, reply-to, CC and BCC, custom headers and templates are the same call with more fields.
curl https://app.usenotix.dev/api/v1/emails \
-H "Authorization: Bearer $NOTIX_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"from": "receipts@acme.com",
"to": "customer@example.com",
"subject": "Your receipt",
"html": "<p>Thanks for your order.</p>"
}'
Typed SDKs where they help, a plain JSON endpoint everywhere else. Nothing here needs a client library to work.
import { Notix } from "notix-js";
const notix = new Notix(process.env.NOTIX_API_KEY);
const { data, error } = await notix.emails.send({
from: "receipts@acme.com",
to: "customer@example.com",
subject: "Your receipt",
html: "<p>Thanks for your order.</p>",
});
Pass an Idempotency-Key header (up to 256 characters) on a send or a batch send. Notix stores the canonical request body against that key and returns the original result if the same request arrives again, so a timeout your client retried does not become a second receipt in someone's inbox. Reusing a key with a different body is an error rather than a silent second send.
order-4821-receipt, not retry-3.curl https://app.usenotix.dev/api/v1/emails \
-H "Authorization: Bearer $NOTIX_API_KEY" \
-H "Idempotency-Key: order-4821-receipt" \
-H "Content-Type: application/json" \
-d '{ "from": "receipts@acme.com", "to": "customer@example.com",
"subject": "Your receipt", "html": "<p>Thanks.</p>" }'
Register an endpoint in the dashboard and Notix posts events as they happen, so your system learns what became of a message without polling for it.
email.queued, email.sent, email.delivered, email.delivery_delayed, email.bounced, email.complained, email.rejected, email.suppressed, email.failed, email.cancelled, email.rendering_failure, email.opened and email.clicked.
contact.created, contact.updated and contact.deleted for contact-book changes; domain.created, domain.verified, domain.updated and domain.deleted for sending domains. webhook.test fires on demand, so you can prove your endpoint works before you rely on it.
Narrative reference docs are being written and are not published yet. Until they are, the machine-readable specification the API itself serves is the complete and current source: every endpoint, every field, every response. It needs no API key to read.
The JSON document. Point your client generator, your editor or an HTTP client at it.
https://app.staging.usenotix.dev/api/v1/docThe same specification rendered as browsable documentation you can read endpoint by endpoint.
https://app.staging.usenotix.dev/api/v1/uiSomething missing or wrong? Tell us. It is a small team and the reply comes from a person.
Verify a domain, copy an API key, make one call. The free plan does not ask for a card.