From sign-up to your first email.

• An AWS account. Free to open at aws.amazon.com (AWS asks for a card). You pay AWS directly for the emails you send; Ops-Free doesn't sit in the middle of that bill.
• Somewhere to send from. Either a domain you can edit DNS for (best for inbox placement), or just your email address if you don't have one yet.
• About 15 minutes. DNS changes can take longer, but you can do the rest while you wait.

How it works: your app calls the Ops-Free API, we queue and send the message through your SES account, and we track what happens next. With one-click connect no secret is stored: we use a role in your account for short-lived sessions, and you can cut off access any time by deleting its CloudFormation stack in AWS. (Connecting with an access key instead stores the key encrypted.)

The dashboard shows the same steps in the same order, with forms in place. This page explains what each one is for and what to do when it doesn't go as expected.

1. 1

   Create your Ops-Free account

   Takes a minute. This is separate from your AWS account.

   1. Go to Sign up and enter your email and a password of at least 8 characters.
   2. Open the confirmation email if you're asked to, then sign in.

   You'll know it worked when you land on a page titled “Let's get you sending”.

2. 2

   Connect your AWS account

   Ops-Free needs permission to send through your SES account. One click creates a dedicated, limited role for it: no AWS login, no access key.

   Option A: one-click connect (recommended)

   1. In the dashboard, open AWS (or the first setup step). Choose the region where your SES account lives (for example ap-south-1) and click Connect AWS.
   2. A new tab opens on AWS's Create stack page, already filled in. Sign in to your AWS account if asked.
   3. Scroll to the bottom, tick the box acknowledging that AWS will create an IAM role, and click Create stack.
   4. Go back to Ops-Free. It says “Waiting for AWS” and turns to Connected by itself, usually within a minute. You can close the AWS tab.

   The stack creates one IAM role in your account. Only Ops-Free can use it, only with a random ID made for your connection, and only for short sessions of 15 minutes. Its permissions are the same ones listed under Option B. You can read the template before you create it. To cut off access, delete the stack in AWS (CloudFormation → the stack named OpsFreeSES-… → Delete).

   Option B: an IAM access key (advanced)

   Use this if you can't create CloudFormation stacks, or prefer a key. It's under “Advanced” in the dashboard.

   1. In the AWS console, open IAM → Users → Create user. Name it ops-free. Leave “console access” off and click through to create it.
   2. Open the new user → Add permissions → Create inline policy → JSON. Paste this policy and save it:

   IAM policy (JSON)Copy policy

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "ses:GetAccount",
           "ses:SendEmail",
           "ses:CreateEmailIdentity",
           "ses:GetEmailIdentity",
           "ses:CreateConfigurationSet",
           "ses:CreateConfigurationSetEventDestination",
           "ses:UpdateConfigurationSetEventDestination",
           "ses:PutEmailIdentityConfigurationSetAttributes",
           "sns:CreateTopic",
           "sns:Subscribe"
         ],
         "Resource": "*"
       },
       {
         "Effect": "Allow",
         "Action": [
           "route53:ListHostedZonesByName",
           "route53:ChangeResourceRecordSets"
         ],
         "Resource": "*"
       }
     ]
   }

   It allows sending, identity checks, event setup and (optionally) DNS publishing in Route 53. Nothing else in your account.

   3. Still on the user, open Security credentials → Create access key and choose “Application running outside AWS”. Copy the Access key ID and the Secret access key. AWS shows the secret once.
   4. Back in Ops-Free, paste both into the connect form with your AWS region. Use the region where your SES account lives; domains and the sandbox are per region.

   You'll know it worked when the step turns green and shows “Connected” with your region. It tells you if your account is still in the SES sandbox.

   Not working? See stuck on “Waiting for AWS”, access denied and which region to use.

3. 3

   Verify where your emails come from

   Amazon only sends from addresses it knows are yours. Pick one option.

   Option A: a domain (recommended)

   1. Type your domain, like yourapp.com, and submit. Ops-Free creates it in your SES account and shows three CNAME records.
   2. Add those three records where your DNS is managed (GoDaddy, Namecheap, Cloudflare, Route 53…). Use the copy buttons. Many registrars want only the part before your domain in the Name field.
   3. Wait. The page checks on its own, usually within minutes; DNS can take up to 72 hours.

   If your DNS is in the same AWS account (Route 53), the records are added for you. Optionally, add an SPF record that includes amazonses.com. If you already have one, edit it rather than adding a second.

   Option B: just an email address

   1. Choose “Don't have a domain?”, enter your address and submit.
   2. Amazon emails you a confirmation link. Click it, then press “I've clicked the link”.

   You can send as that address straight away, including after you go live. You can add a domain later for better inbox placement.

   You'll know it worked when it shows “verified” in green.

   Stuck on pending? DNS troubleshooting.

4. 4

   Create an API key

   The key is what your code uses to send. You can create it while DNS is still propagating.

   1. Click Create API key.
   2. Copy it now. It's shown once and can't be recovered. Store it as a secret in your app (for example an environment variable named OPSFREE_API_KEY), never in code.

   You'll know it worked when you see a key starting with sk_live_ and a ready-to-run example request.

5. 5

   Send a test email

   Goes through the real pipeline: queue, your SES account, outcome tracking.

   1. Use the test form on the setup page, or run the example request from step 4.
   2. In the SES sandbox you can only send to verified addresses. To test without that limit, send to success@simulator.amazonses.com.

   You'll know it worked when the email appears in Activity as sent. That's the setup complete; the page becomes your dashboard.

6. 6

   Track deliveries and bouncesAutomatic

   Set up for you when you connect AWS. It's what turns “sent” into delivered, bounced or complained, and blocks bad addresses automatically.

   1. Nothing to do: this runs as soon as your AWS account connects.
   2. If the dashboard still shows Connect events, click it. If AWS refuses, it tells you which permission is missing.

   In your AWS account this creates an SNS topic named ops-free-ses-events and an SES configuration set named ops-free, and subscribes Ops-Free to it. You can delete both in AWS at any time. Pressing the button again repairs a half-finished setup.

   You'll know it worked when a test email to success@simulator.amazonses.com moves from sent to delivered within a few seconds.

7. 7

   Start sending to anyoneBefore going live

   New AWS accounts are in the SES sandbox: only verified recipients, 200 emails a day. Production access lifts that.

   1. Open Start sending to anyone in the dashboard.
   2. Answer the few questions. Ops-Free writes the request to AWS for you.
   3. Submit it in the AWS console as shown. AWS usually replies within about a day.

   You'll know it worked when the dashboard no longer shows the “SES sandbox” label on your connection.

You can skip most of the walkthrough. Your SES account, quotas and verified identities stay exactly as they are, and anything that sends to SES directly keeps working. Ops-Free just adds an API, queueing, retries, a blocked list and outcome tracking on top.

1. Create or reuse an IAM user. A dedicated user is safer. If you reuse one, make sure it can do the following:

2. Connect it with the region where your identities live (step 2 above).
3. Add your domain. If it already exists in that region, Ops-Free adopts it instead of failing and reads its current status, so a verified domain shows verified straight away. You won't need to touch DNS again.
4. Create an API key and switch your calls to the Ops-Free API.
5. Optionally connect events. Read the note below first.

Two things to know before connecting events. It sets the ops-free configuration set as the default on the domains you add here, replacing any default you had on that identity. And only emails sent through Ops-Free appear in Activity; mail you send straight through SES isn't tracked here.

If your account is already out of the sandbox, there's nothing more to do. If it isn't, see step 7.

One endpoint, POST https://www.opsfree.in/api/v1/send, authenticated with your API key as a bearer token. It validates the request, checks your blocked list, stores the message and queues it, then answers 202 before delivery finishes. Track the outcome in Activity or from the id it returns.

curl -X POST https://www.opsfree.in/api/v1/send \
  -H "Authorization: Bearer sk_live_your_key_here" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: welcome-asha-001" \
  -d '{"from":"hello@yourdomain.com","to":["customer@example.com"],"subject":"Welcome aboard","html":"<h1>Hello {{name}}</h1><p>Thanks for signing up.</p>","variables":{"name":"Asha"}}'

const res = await fetch("https://www.opsfree.in/api/v1/send", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.OPSFREE_API_KEY}`,
    "Content-Type": "application/json",
    "Idempotency-Key": "welcome-asha-001",
  },
  body: JSON.stringify({
      "from": "hello@yourdomain.com",
      "to": [
          "customer@example.com"
      ],
      "subject": "Welcome aboard",
      "html": "<h1>Hello {{name}}</h1><p>Thanks for signing up.</p>",
      "variables": {
          "name": "Asha"
      }
  }),
});

// 409 means this Idempotency-Key was already used: the first call went through.
if (res.status !== 202 && res.status !== 409) {
  const { error } = await res.json();
  throw new Error(`${error.code}: ${error.message} (request ${error.requestId})`);
}
const { id } = await res.json(); // keep this to look the email up later

import os, requests

res = requests.post(
    "https://www.opsfree.in/api/v1/send",
    headers={
        "Authorization": f"Bearer {os.environ['OPSFREE_API_KEY']}",
        "Idempotency-Key": "welcome-asha-001",
    },
    json={
        "from": "hello@yourdomain.com",
        "to": ["customer@example.com"],
        "subject": "Welcome aboard",
        "html": "<h1>Hello {{name}}</h1><p>Thanks for signing up.</p>",
        "variables": {"name": "Asha"},
    },
)

if res.status_code != 202:
    err = res.json()["error"]
    raise RuntimeError(f"{err['code']}: {err['message']} (request {err['requestId']})")
email_id = res.json()["id"]

{
  "id": "3f2a1c9e-8d44-4a6b-9f10-2b7c5e0d1a33",
  "status": "queued",
  "message": "Accepted for asynchronous delivery"
}

{
  "error": {
    "code": "DOMAIN_NOT_VERIFIED",
    "message": "...",
    "requestId": "req_..."
  }
}

Errors are JSON with a stable code. Branch on the code, not the message text.