From nothing to a sent message, in minutes

Start here: from nothing to a sent message

Documentation is organised around what you're trying to do, not around the shape of the API, because developers scan rather than read and the first thing almost everyone wants is a single message out the door. There are two ways to send — SMTP relay and the REST API — and you can be live on either within minutes once your domain's DNS is in place. Pick the one that matches how your application already works; neither is more capable, they're different integration shapes for different situations. The reference for every endpoint, parameter and response code lives in the full API reference; this page is the map and the quickstart that gets you to your first successful call.

Option A — SMTP relay, if your app already speaks SMTP

If your framework or application already sends mail over SMTP, this is a configuration change rather than a code change. Point your SMTP client at the relay with your credentials over an encrypted port — 587 with STARTTLS, or 465 with implicit TLS — and you're sending:

SMTP configurationHost:     smtp.authorizehosting.com
Port:     587          (STARTTLS)  ·  or 465 (implicit TLS)
Username: your-sending-identity
Password: your-relay-key
TLS:      required — the relay refuses plaintext

That's the whole integration for most senders. The one thing worth doing before you send in volume is confirming your authentication is in place, because the relay accepting your message and the recipient's inbox accepting it are two different things — see the authentication section below.

Option B — the REST API, if sending lives in your code

If you'd rather the sending logic sit in your application with structured responses and webhooks, the REST API follows predictable conventions: a Bearer token in the Authorization header, a JSON body, and a JSON response with a stable schema. Here's the minimal first call, with the credential read from an environment variable rather than hardcoded — a small thing that matters, because a docs example that hardcodes a secret teaches an insecure habit:

First API call — curlcurl https://api.authorizehosting.com/v1/send \
  -H "Authorization: Bearer $AUTHORIZE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "alerts@yourdomain.com",
    "to": "customer@example.com",
    "subject": "Order #4821 confirmed",
    "stream": "transactional",
    "text": "Your order is on its way."
  }'

A successful submission returns 202 Accepted with a message identifier you can correlate against webhook events later. The stream field is worth setting from the first call: it routes the message to the right virtual MTA so your transactional and bulk traffic carry separate reputations, which is one of the reasons to be on dedicated infrastructure in the first place.

The thing most quickstarts skip: failure modes

When documentation only shows the success case, developers discover the failure modes through trial and error in production, which is the worst place to learn them. So here are the responses worth handling from the start. A 202 means accepted for delivery. A 401 means the API key is wrong or missing. A 422 means the request was understood but a field is invalid — a malformed address, a missing required field. A 429 means you're being rate-limited and should back off and retry. And on the SMTP side, the distinction that matters is the one covered in the glossary: a 421 is a temporary deferral to retry, a 550 is a permanent rejection to stop and investigate.

One pattern worth building in from the start: idempotency. If a network blip makes you unsure whether a send succeeded, retrying without an idempotency key risks sending twice. Including one lets the API recognise the retry and avoid the duplicate — the kind of production consideration a minimal snippet omits but a real integration needs.

Authentication: the part that decides whether any of this reaches the inbox

Getting a 202 back means the message was accepted by us, not that it will land in the recipient's inbox — and the gap between those is almost entirely about domain authentication. Before sending in volume, three DNS records need to be right: SPF authorising the relay, DKIM signing your messages, and DMARC telling receivers how to handle failures. On managed plans the operator team sets these up with you; on any plan you can verify them yourself with the free tools — the DMARC checker, SPF flattener and DKIM tester — which read back exactly what a receiving server sees. The deliverability fundamentals page explains why this layer matters more than anything in your sending code.

Webhooks: knowing what happened after you sent

The API accepting a message is the start of its life, not the end. Webhooks deliver the events that follow — delivered, bounced, complained, opened where tracked — to an endpoint you control, with structured authentication-result fields so you can see not just that a message bounced but whether it failed authentication on the way. The v2 payload schema carries these structured fields; the older v1 format is deprecated but supported through at least the end of 2026, as noted in the changelog. Build your handler to verify the webhook signature and to be idempotent, since at-least-once delivery means an event can arrive more than once.

How the documentation is organised

Beyond this quickstart, the documentation follows developer workflows rather than the API's internal structure. There's a getting-started path that takes you from account to first send; an authentication section covering both API credentials and the SPF/DKIM/DMARC email-authentication layer; a sending reference for every parameter on both SMTP and REST; a webhooks section with every event type and payload; and a migration path if you're moving an existing integration from another provider, which is mostly a field-mapping exercise documented per source provider. Endpoint descriptions explain the business purpose, not just the mechanics — what a call is for, not only what it does.

When the docs don't answer it

Documentation answers the questions that generalise. Email infrastructure also generates a long tail of specific situations — an unusual SMTP client, a deliverability pattern particular to your recipient base, a migration with a wrinkle the standard guide doesn't cover. For those, the fastest path isn't searching for a doc that may not exist; it's asking the operator team, who on managed plans are the same people running the infrastructure rather than a separate support tier reading from a script. Good documentation answers a developer's question before they ask it; an honest provider also makes it easy to ask the questions documentation can't anticipate.