lettr-com Diagnose Lettr delivery problems
The job is interpretation. Fetch the relevant data from Lettr, then read the result against the references in this skill to tell the user what's wrong and how to fix it.
Triage by symptom
Pick the row that matches what the user is reporting.
| Symptom | What to fetch | Reference |
|---|---|---|
| "I sent an email, the user never got it" | Email events filtered by recipient (last hour) | bounce-classes.md, webhook-events.md |
"I get 400 unconfigured_domain / domain rejected when sending" |
Domain list, then details for the failing one | dns-failures.md |
| "I added a domain but it stays pending" | Trigger verification, then re-fetch the domain | dns-failures.md |
| "Webhook isn't firing for my events" | Webhook list, then details for the suspect one | webhook-events.md |
| "I'm getting 429 / quota exceeded" | Validate API key, then read the response payload | quota-rate-limits.md |
| "Open / click tracking shows nothing" | Event detail for one known send | webhook-events.md — engagement events |
General flow
- Reproduce by request_id when possible. If the user has a
request_idfrom a recent send, fetch its event timeline first — it's the cheapest lookup. - Otherwise filter by recipient. Pull email events filtered by the affected address, narrowed to the relevant time window.
- Read the latest event. The chronologically last event is usually decisive.
deliverymeans the receiving server accepted it (problem is downstream — spam folder, user error).bounce,policy_rejection,out_of_band, ordelaymean Lettr couldn't or didn't fully deliver — read the reference to interpret the class. - Confirm setup before suspecting bugs. If a fresh integration is misbehaving, validate the API key and list domains first. Most early-stage problems are unverified domains or
fromaddresses on the wrong domain.
What this skill does NOT do
- It does not read user mailboxes. If a user reports "I didn't get the email" but Lettr shows
delivery, the message is in their inbox/spam — the user must check. - It does not repair DNS at the user's registrar. The skill explains what's wrong; the user fixes it at Cloudflare/Route53/etc.