"Account in Quarantine" on `platform_service_email` - ErrorCode 440

General
1

Hi ServiceM8 team,

I’m developing an add-on that sends outbound emails on behalf of accounts via POST /platform_service_email. During testing today my account was placed into a quarantine state and I’d appreciate some help understanding why, how long it lasts, and what I should design my add-on to do about it.

The rejection I’m seeing

Every send is now returning:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "errorCode": 440,
  "message": "Sending Email rejected due to Account in Quarantine",
  "messageID": "4766022f-43c3-4688-ab58-241e000c197b",
  "submittedAt": "2026-04-26T08:12:15+00:00"
}

Note this is HTTP 400 + errorCode 440 — distinct from the 429 rate-limit / quota path that’s documented in the Messaging Overview.

What I was doing when it triggered

Full transparency so you can see whether my pattern matches the trigger:

  • Roughly a dozen sends over ~10 minutes
  • Same recipient most of the time (my own personal address)
  • Very short / repetitive subjects + bodies ("test", "sdf", occasional gibberish I was using to test how my add-on classifies spam-like content)
  • A few of the sends had attachments

I’m guessing it’s the combination of repeat recipient + repetitive content + burst rate from a freshly-active sender, but that’s purely a guess — and I clearly didn’t hit the documented 429 path, so this is something separate.

What I’d like to ask

About the quarantine itself

  1. Could you release the quarantine on my account so I can continue development? The messageID above should let you find the exact rejection in your logs.
  2. What actually triggered it? Was it the repeat recipient, the content similarity, the burst rate, the gibberish content being flagged as spam, or some combination? Even a rough description would let me adjust my testing approach and pre-empt it for customers.
  3. What’s the duration? Is errorCode 440 a rolling time window (like the documented Sending Quota), or does it require manual release every time?
  4. Is there a soft signal before the hard block? Something my add-on could detect (“you’re approaching the quarantine threshold”) so I can warn the customer pre-emptively rather than just failing their send.
  5. What is the complete list of errorCode values platform_service_email can return? I’m pretty sure I saw a different rejection earlier today that read like a content/spam flag rather than a quarantine, but I didn’t capture the body. A complete list would let me build proper error-handling and customer-facing messages instead of a generic “send failed”.

About sending quotas (the documented path)

The Messaging Overview describes the Sending Quota as a rolling 24-hour cap, with the example “if your email sending quota is 500…” — which leads to a few practical questions:

  1. Is 500/day the actual starting quota for new add-on installs, or just an illustrative figure in the docs? Knowing the real default would let me set sensible expectations with customers on day one.
  2. Is the quota per-add-on, per-account, or per-add-on-per-account? i.e. if my add-on is installed on 100 customer accounts, does each installation get its own 500/day, or is it shared across the add-on?
  3. Can my add-on read the current quota and remaining headroom? Right now I have no programmatic way to know how close a customer is to their cap until they get the 429. Two suggestions, easiest first:a. Return quota headers on every successful platform_service_email response, e.g.
X-SM8-Quota-Limit: 500
X-SM8-Quota-Remaining: 347
X-SM8-Quota-Reset: 2026-04-27T08:12:15Z

This is the standard pattern (GitHub, Stripe, AWS API Gateway all do this) and would let add-ons surface a “you have 153 sends left today” indicator without a separate API call.b. Return the quota numbers in the 429 response body too, so add-ons can give customers a precise “your 500/day cap will reset in 6 hours” message instead of a generic “rate-limited” toast.Would either of these be considered for a future API revision? Even just (a) on success responses would dramatically improve add-on UX.
9. Are there per-account daily caps distinct from the per-add-on quota? Specifically for platform_service_email?

Documentation feedback

Just to flag the gap I ran into — neither /reference/send_email nor /docs/http-response-codes currently mention errorCode 440, “Account in Quarantine”, or any anti-spam hold. The send_email reference only documents 200, 400, and 429. Adding 440 (and any other codes from question 5) to the public docs would let add-on developers like me build sensible UX around them.

Why this matters for my add-on

When my add-on ships to customers, they’ll occasionally hit both paths — quotas from heavy legitimate usage, and quarantine if their content/sending pattern looks suspicious. If I can’t translate errorCode 440 (or even a 429) into a meaningful, actionable message — “your ServiceM8 account is temporarily restricted; here’s why, here’s when it clears” — they’ll blame my add-on for what’s actually a platform-level block. Clarity on items 2–9 above lets me get that customer experience right.

Thanks!
Dave

2

I’m pretty sure you get this error when the trial has expired, are you sure the account is not out of trial.

1 Like
3

Hi Dave,

What you’re seeing matches an account quarantine scenario where outbound email/SMS sending can be blocked after suspected spam or unsafe sending activity.

When a quarantine is active, outbound sending can remain blocked until a review is complete, and in some cases there can also be separate account access or billing issues that need to be cleared as part of restoring normal sending.

Separately to quarantine, the Messaging API docs describe sending limits as (1) a rolling 24-hour Sending Quota and (2) a Maximum Send Rate, and when those limits are reached the API returns 429 Too Many Requests with either “Maximum sending rate exceeded” or “Daily message quota exceeded”. The “500” figure mentioned in the docs is explicitly an example, rather than a guaranteed default quota for every account.

On the specific endpoint, the POST /platform_service_email reference currently documents 200, 400 (example: “Invalid email address”), and 429 responses, and doesn’t yet include errorCode 440 in its examples.

To get the quarantine reviewed (and to pass on your documentation feedback like adding 440 and publishing/returning quota visibility), email support@servicem8.com with your ServiceM8 account email, when the block started, and an example of the last email/SMS content that triggered it, along with the messageID from the API response.

Thanks,
Cody

4

Thanks very much for getting back to me, Cody, appreciate it.

I did end up sending this through to support and it’s all been resolved now, they lifted the quarantine on the account.

Just for anyone else who runs into this, here’s the key info I got back from support:

What triggers quarantine

  • It’s not purely rate-limit based
  • Triggered by spam detection behaviour, such as:
    • Repetitive sends (as little as 4–5 in quick succession)
    • Multiple messages to the same recipient without replies
    • Patterns that look like unsafe or spammy sending

What happens when you’re quarantined

  • Outbound email and SMS are blocked
  • Remains blocked until support reviews and lifts it
  • There’s no documented automatic clear timeframe

Early warning signals

  • There are none
  • You won’t get a “heads up”
  • The first real signal is the error itself (e.g. errorCode 440)

Rate limits (separate to quarantine)

  • These are still in place and behave differently:
    • Rolling 24-hour sending quota
    • Maximum send rate
  • When exceeded, you’ll get 429 errors, not 440

My testing scenario (what triggered it)

In my case, I was testing a custom add-on on a dev account and triggered it pretty easily by:

  • Sending multiple emails in quick succession
  • Same recipient (myself)
  • Repetitive / low-quality content (including some gibberish while testing)

Also worth noting:

  • This was a dev account with sporadic usage, not a consistently active sender
  • So account reputation likely plays a role as well

Dev feedback / suggestion

One thing I’d still love to see from a developer perspective is quota visibility in headers, something like:

  • Limit
  • Remaining
  • Reset time

That would make it much easier to build proper UX around this and avoid hitting these states in the first place.

Hopefully that helps anyone else who runs into the same thing :+1:

5

Hi Dave,

Michael’s suggestion to check trial/billing status is a fair one, because send failures can also be caused by account-status issues (for example, an expired subscription or unpaid balance).

That said, “Account in Quarantine” is typically a separate temporary state where outbound email and SMS sending can be blocked after suspected spam activity, and it can stay blocked until a Support review is complete.

On the docs side, the public /platform_service_email reference currently only documents 200, 400, and 429 responses, so it doesn’t currently cover quarantine-style rejections like the one you’re seeing.

Email us at support@servicem8.com with the messageID, the submittedAt timestamp, and the ServiceM8 account you were sending from, and we can review the quarantine and advise on next steps.

Thanks,
Cody

1 Like
6

Thanks mate this has been resolved

7

Hi Dave,

Appreciate you sharing the outcome and the extra context for other developers.

For anyone else implementing POST /platform_service_email, the Messaging API has two separate sending limits: a rolling 24-hour Sending Quota and a Maximum Send Rate.

When either sending limit is exceeded, the API returns 429 Too Many Requests with either “Maximum sending rate exceeded” or “Daily message quota exceeded”.

The “500” number mentioned in the docs is given as an example to explain how the rolling 24-hour quota works (rather than a published default quota).

On /platform_service_email, both success (200) and error responses (including 400/429) return the same SendResult payload shape with an errorCode and human-readable message, so those are the best fields to drive customer-facing error handling in an add-on.

Docs links for anyone following along:

That should help other developers who land on this thread.

Thanks,
Cody