Can it replace Mailgun in existing code?

For sending, usually yes. The Mailgun-compatible endpoint takes the same path shape, the same multipart fields and the same api:KEY basic auth, and answers in Mailgun’s response shape — so most client libraries repoint by changing a base URL. It is not a full Mailgun clone: there is no marketing tooling, and the ceilings below are real.

Do I need a Sage 100 install to use it?

No. The Alerts API is independent of the Sage 100 API — no connector, no ERP, no conversation first. Registration is self-serve and the two products only share an account boundary.

Is the log a real log store or just a copy of the email?

A real store, and it works without sending anything. Write to a named bucket with POST /api/log, then filter reads by level, source, dot-notation event and time range. Attaching a log entry to a send is a convenience on top of that, not the only way in.

How long are logs kept?

30 days, then they are deleted. This is an operational trail rather than an archive — if something has to survive a quarter, write it somewhere that promises to keep it.

Available now

The Alerts API: email your jobs can send, and a log you can actually read.

Every scheduled job, connector and back-office integration eventually needs to tell someone that something went wrong — and needs to leave a trail explaining why. The Alerts API is both: a transactional email API and a structured log store, behind one API key.

curl -X POST https://api.alerts.sconnect.io/api/email/send \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "alerts@example.com",
    "to": "ops@example.com",
    "subject": "Sync failed",
    "textBody": "File sync failed after 3 retries.",
    "logBucket": "file-processor",
    "logLevel": "error",
    "logEvent": "sync.failed"
  }'

Get started Read the docs Sign in

If you already send through Mailgun, this is a base URL

The Mailgun-compatible endpoint takes the same path shape, the same multipart form fields and the same api:KEY basic auth, so most Mailgun client libraries repoint without touching the call sites.

curl -X POST https://api.alerts.sconnect.io/v3/example.com/messages \
  --user "api:YOUR_API_KEY" \
  -F from="Server Alerts <alerts@example.com>" \
  -F to=ops@example.com \
  -F subject="Server Alert" \
  -F text="CPU usage exceeded 90% on prod-web-01."

It answers in Mailgun’s shape too — { "id": ..., "message": "Queued. Thank you." } — so response-parsing code survives the move. The REST endpoint returns { "success": true, "messageId": ... } instead, which is the nicer one to write against if you are starting fresh.

What it does

Two ways to send, one of them already in your code

A plain REST endpoint at POST /api/email/send, and a Mailgun-compatible POST /v3/{domain}/messages that accepts --user "api:KEY" basic auth. Text, HTML, or both with a fallback. Attachments go base64 on the REST endpoint and multipart on the Mailgun one.

Log buckets, not a log file on a box you cannot reach

Named channels you create from the dashboard and write to with POST /api/log. Each entry carries a level, a source and a dot-notation event like order.created, plus a JSON properties blob — and you filter on all of them, and on a time range, when you read them back.

The alert and the reason for it, in one call

Add logBucket, logLevel, logEvent and friends to a send and the log entry is written alongside the email. The thing that fired the alert and the alert itself stop being two systems you have to correlate by timestamp.

Email logging with no code at all

Designate a bucket as your email log in the dashboard and every message records its subject, sender and recipient automatically. Nothing to add to the call sites — useful when the sending code is a scheduled job nobody has opened in two years.

The limits, before you find them

Same rule as everything else here: the edges are on the page, not discovered in week two.

500 a day, 5,000 a month: Hard ceilings, and GET /api/email/usage tells you where you are against both. This is sized for operational alerting and integration traffic, not for a marketing send.
Three buckets per account: Pick the axis that will still make sense in a year — usually the integration, not the environment. Buckets are created from the dashboard, and a log write to a bucket that does not exist yet is an error rather than an implicit create.
Logs are deleted after 30 days: This is an operational trail, not an archive and not your audit record. If something has to survive a quarter, write it somewhere that promises to keep it.
The from address has to be verified: You cannot send as an address the account has not proven it controls, which is the same rule every reputable sender applies. Set a display name with fromName, or with "Display Name <email@domain>" on the Mailgun endpoint.
Sizes are capped: Attachments total 25 MB per message. A log message is 2,000 characters and properties is 4,000 — worth knowing before you pipe a stack trace straight into either.

The reference has the rest — every request field, the bucket management endpoints, and worked examples for attachments.

Questions people ask first

Can it replace Mailgun in existing code?: For sending, usually yes. The Mailgun-compatible endpoint takes the same path shape, the same multipart fields and the same api:KEY basic auth, and answers in Mailgun’s response shape — so most client libraries repoint by changing a base URL. It is not a full Mailgun clone: there is no marketing tooling, and the ceilings below are real.
Do I need a Sage 100 install to use it?: No. The Alerts API is independent of the Sage 100 API — no connector, no ERP, no conversation first. Registration is self-serve and the two products only share an account boundary.
Is the log a real log store or just a copy of the email?: A real store, and it works without sending anything. Write to a named bucket with POST /api/log, then filter reads by level, source, dot-notation event and time range. Attaching a log entry to a send is a convenience on top of that, not the only way in.
How long are logs kept?: 30 days, then they are deleted. This is an operational trail rather than an archive — if something has to survive a quarter, write it somewhere that promises to keep it.

Nothing to install, and nobody to ask

Registration is self-serve, and the dashboard is where you create an API key, add a verified from address and set up your buckets. Unlike the Sage 100 API, this needs no connector on a box somewhere and no conversation first — you can be sending before you finish reading the reference.

Get started Sign in Talk to us