Sending approval

A new workspace cannot send email until we have reviewed it. Not transactional API sends, not SMTP, not campaigns, not test sends. Everything else works from the moment you sign up — add domains, verify DNS, mint API keys, import contacts, build campaigns — but nothing leaves the building until the workspace is approved.

Most requests are answered within 24 hours.

Why

Deliverability is shared. Every account that sends from Envloped is sending from IP addresses and domains that every other account's mail also depends on, so one list bought from a broker is not that account's problem — it is everyone's. Reviewing new accounts before their first send is the cheapest point at which that is preventable; afterwards the only tools left are suspension and apology.

It also means the review is genuinely about the answers you give us, not about your card or your traffic. A one-line description of where your recipients come from is usually enough.

Requesting approval

Go to Settings → Sending approval and answer two questions:

Expected volume — roughly how many emails you expect to send, or how many contacts you plan to reach. An estimate is fine; nobody holds you to it.

What you plan to send — the email types and, most importantly, where the recipients come from. This is the answer that decides the review.

A good answer is specific and boring:

Password resets and order receipts from our app, plus an optional product newsletter for customers who tick a box at checkout.

A weak answer is one that could describe anybody:

Marketing emails to our users.

You can withdraw a pending request and edit it. If a request is declined you will get the reason by email, and you can submit a new one after 24 hours.

The API refusal

While a workspace is unapproved, every send path answers 403:

{
  "error": "This workspace has not been approved to send email yet. Request approval in Settings → Sending approval; most requests are answered within 24 hours.",
  "code": "sending_not_approved",
  "approval_status": "not_requested",
  "approval_url": "https://envloped.com/settings/sending-approval"
}

approval_status is one of not_requested, pending or rejected, and the three want different things from you — respectively: fill in the form, wait, and read the emailed reason.

Never retry it

Same rule as 402, for a stronger reason. A 429 clears by waiting and a 402 clears when money moves; this one clears only when a person at Envloped makes a decision. A backoff loop against a review queue is a slower way to do nothing.

If your client has a blanket retry policy for "server said no", make sure neither 402 nor 403 is in it. The Envloped SDKs and the CLI do not retry either.

import { ForbiddenError } from '@envloped/envloped-js'

try {
  await envloped.emails.send({ from, to, subject, html })
} catch (err) {
  if (err instanceof ForbiddenError && err.isSendingNotApproved) {
    // Not a transient failure. Surface it to a human, do not retry.
    console.error(`Sending is not approved yet: ${err.approvalUrl}`)
  }
}

_, err := client.Emails.Send(ctx, req)
if errors.Is(err, envloped.ErrSendingNotApproved) {
    // Not a transient failure. Surface it to a human, do not retry.
    log.Printf("sending is not approved yet")
}

How this differs from the other refusals

Four things can stop a send, and they are deliberately distinguishable because the remedies have nothing in common:

Nothing on this page applies to accounts that were already sending before review existed — they are approved, and always were.