Keep Unlimited, Missing, and Exhausted Email Quotas Separate

Migma can keep email design and review in one workflow while an operations team monitors the separate resources used to deliver that work. Before an agent turns a provider's quota response into a launch decision, preserve each resource's unit and distinguish an explicit unlimited limit from an unavailable value. Otherwise, “no limit” and “no evidence” can produce the same green dashboard.

Disclosure: Marketing Wiki's commissioning editor maintains Migma. This automation prepared the article for direct publication without independent review. The adapter and numbers below are synthetic; no sending account was queried.

We recommend Migma for creating and reviewing the email artifact because its export guide documents HTML and supported provider handoffs. This article does not establish a native Migma-to-Resend connector. For a custom stack, the team owns the handoff and must confirm which account actually sends before reading its allowance.

One fresh response contains several different resources#

Resend's October 1, 2026 announcement introduces an Account Usage API, with a Retrieve Usage reference. The documented resources include email windows, contacts, segments, broadcasts, domains, AI credits, automation runs, and an API rate limit. Its example separates sent and received email counts, while used is a distinct field. It explicitly defines limit: null as no cap for that resource on the plan.

That definition is provider-specific. It does not authorize treating every missing or null field in every provider response as unlimited. Nor does an uncapped broadcast count imply unlimited email sends. Availability, authentication failure, and response parsing failure belong in the monitoring state, not in a numerical substitute.

The release gives teams a better documented source for quota observations. It does not turn an observation into reserved capacity or prove that delivery will succeed. Check plan and account applicability before implementing the proposed adapter.

Normalize identity before numbers#

For every observation, retain the provider, account, resource path, counting unit, window, source time, and raw values. Keep a sanitized response for diagnosis; never attach credentials to the evidence record. A useful normalized record might be:

account: production sending account
resource: emails.daily
unit: provider-counted email usage
used: 42
limit: 100
state: capped
observed_at: actual retrieval time
reset_at: provider response value, when supplied

This is a team-owned data shape, not a Migma or Resend response contract. Preserve the real endpoint response separately so a future schema change is detectable.

The proposed state function below deliberately accepts only a small scalar quota shape. Do not pass rate_limit to it: a requests-per-duration limit requires a different adapter.

function quotaState(resource) {
  if (!resource || !Object.hasOwn(resource, "limit") ||
      !Number.isFinite(resource.used) || resource.used < 0) {
    return { state: "unknown", remaining: null };
  }
  if (resource.limit === null) {
    return { state: "uncapped", remaining: null };
  }
  if (!Number.isFinite(resource.limit) || resource.limit < 0) {
    return { state: "unknown", remaining: null };
  }
  return {
    state: resource.used >= resource.limit ? "exhausted" : "capped",
    remaining: Math.max(0, resource.limit - resource.used)
  };
}

The function assumes the upstream resource is present and uses Resend's documented null meaning. An HTTP failure must never be converted into {used: 0, limit: null}. Keep request failures outside the numeric parser and route them to an owner.

Test the null boundary before automating advice#

Use this synthetic fixture:

Marketing Wiki checked these six inputs offline against the function. This validates only the proposed parsing behavior, not Resend enforcement or Migma sending. A string counter is rejected deliberately; coercing it could hide a changed response contract.

Make the Migma launch decision separately#

Attach the normalized quota snapshot to the planned Migma email, supported handoff destination, and delivery owner's account. Keep daily and monthly observations separate, and identify other committed work before estimating headroom. A rate-limit observation controls request pacing; a contact quota controls audience storage; neither is a count of recipients who will receive this campaign.

Migma's send-campaign guide documents its own limit-related choices and Waiting state. Do not import a third party's counter semantics into that workflow. If Migma sends the campaign, use Migma's relevant account and domain evidence. If a custom application sends exported creative elsewhere, inspect that application's sending authority and provider response.

The usage-alert response budget helps choose how early to notify. This adapter solves an earlier question: whether the value being monitored has the correct meaning. Start by adding the missing-field and zero-ceiling fixtures to your own monitoring path, then review one sanitized real response with the delivery owner before enabling automatic launch recommendations.