# setup agent hit sendgrid 429 mid welcome sequence and lost retry state

## TL;DR
The 429 was survivable but the lost state was not: the agent cannot tell sent from unsent. Stop sending, determine who already received mail from SendGrid's activity feed and your logs, persist per-recipient state before each send going forward, add rate limiting and exponential backoff on 429, and resume only for unsent recipients. Verify no duplicates in the activity feed.

```text
setup agent hit sendgrid 429 mid welcome sequence and lost retry state
```

## Use this when

- A welcome sequence stops partway with SendGrid 429 errors
- Re-running the sequence would double-email some users
- Nobody knows who got the welcome email

## Not for this skill when

- SendGrid API key authentication failures (credential problem)
- Template rendering errors on otherwise sent mail (template problem)
- Bounces and spam blocks after successful sends (deliverability)

## Steps

### Step 1: Stop and assess

Halt the agent's sending immediately. Expected: no more mail goes out while state is unknown.

### Step 2: Reconstruct who was emailed

Cross-reference SendGrid's activity feed with your send logs to build the sent list. Expected: a definitive list of recipients already emailed.

### Step 3: Persist per-recipient state

Change the sender to record each recipient's state before sending, not after. Expected: a crash at any point leaves an accurate resume point.

### Step 4: Add rate limiting and backoff

Cap the send rate under SendGrid's limits and back off exponentially on 429. Expected: throttling slows the run instead of breaking it.

### Step 5: Resume for unsent only

Continue the sequence for recipients with no sent state. Expected: every new user gets exactly one welcome email.

### Step 6: Verify no duplicates

Check the activity feed for duplicate sends. Expected: zero recipients emailed twice.

## Tool compatibility

SendGrid email API (rate limits); SendGrid activity feed; idempotent send-state tracking.

## Variant phrasings

### Variant 1

sendgrid 429 welcome email sequence failed

### Variant 2

sendgrid rate limit lost track sent emails

### Variant 3

resume sendgrid bulk send after 429 without duplicates

## Why it happens

SendGrid's 429 is a pacing signal: slow down and continue. But agents that keep send state only in memory turn a pacing signal into a data-loss event the moment they crash or abort on the 429. The real damage is not the throttle but the ambiguity it creates: sent and unsent become indistinguishable, so the team must choose between double-emailing users and leaving some unwelcomed. Persisting state before each send, rather than after, is the one-line architectural fix that makes the whole class of failure resumable. Backoff handles the throttle; the state handles everything else.

## Edge cases / pitfalls

- SendGrid has both account-level and IP-level limits; know which one you hit.
- The activity feed retains limited history; export send state to your own store promptly.
- Template version mismatches can 400 where you expect 429; read the error before assuming throttle.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_orqZgtcuYtwCiMglmjtvfg