# Was the email sent, or was it delivered? > Was the email sent, or was it delivered? The 4 completion levels, the Resend lifecycle, and the evidence Provely reads. Certification Community. Canonical: https://provely.sh/verify/resend Last reviewed: 2026-09-05 Skill version: 0.1.0 Certification: community **No. Resend returns a send response with an email id when it accepts the request. The email then holds one of 12 states. Provely proves `accepted`, `bounced`, `delivered` and `sent` as separate promises.** *Skill facts from the signed manifest.* | Fact | Value | | --- | --- | | Skill version | `0.1.0` | | Certification | Community (score 49 of 100) | | Last conformance run | 2026-09-05T12:00:00Z: 58 of 60 cases passed, 0 critical false VERIFIED | | Provider API versions | `1.5.1` | | Default provider API version | `1.5.1` | | Compiled | 2026-09-05T12:00:00Z by compiler 0.1.0 | | Manifest hash | `bb3243d9753c7608` | | Manifest hash check | the document hashes to the value the manifest states | | Signature | valid, key `provely-test-key-1`, not in the trusted key map of this build | ## What does this page prove? | Claim | Proven by | Evidence | Status | | --- | --- | --- | --- | | The accepted level proves that Resend holds an email record for the request. It does not prove that the message left the provider. | [resend.email.accepted](/verify/resend/resend.email.accepted) | E2 | proven | | The bounced level proves the bounced state on the email record and the email.bounced event. Use it when the intent is to confirm a rejection, for example before a suppression. | [resend.email.bounced](/verify/resend/resend.email.bounced) | E2 + E3 | proven | | The delivered level proves the delivered state on the email record and the email.delivered event. It does not prove that a person read the message. This level needs the email.delivered webhook. | [resend.email.delivered](/verify/resend/resend.email.delivered) | E2 + E3 | proven | | The sent level proves the email.sent event of this email. It does not prove that the recipient mail server accepted the message. This level needs the email.sent webhook. | [resend.email.sent](/verify/resend/resend.email.sent) | E2 + E3 | proven | | An outcome outside Resend, such as a bank credit or a person who read a message | not proven | no E5 channel | not proven | | The agent report that the action worked | never counts | E0 | not proven | ## Which completion levels does the Resend skill expose? Each level is one promise with one contract. An agent picks the level that matches the promise it makes. It cannot upgrade a level. Read the [completion level](/glossary/completion-level) definition. | Level | Contract | Promise | Evidence | Certification | | --- | --- | --- | --- | --- | | `accepted` | [resend.email.accepted](/verify/resend/resend.email.accepted) v1.0.0 | The accepted level proves that Resend holds an email record for the request. It does not prove that the message left the provider. | E2 | Community | | `bounced` | [resend.email.bounced](/verify/resend/resend.email.bounced) v1.0.0 | The bounced level proves the bounced state on the email record and the email.bounced event. Use it when the intent is to confirm a rejection, for example before a suppression. | E2 + E3 | Community | | `delivered` | [resend.email.delivered](/verify/resend/resend.email.delivered) v1.0.0 | The delivered level proves the delivered state on the email record and the email.delivered event. It does not prove that a person read the message. This level needs the email.delivered webhook. | E2 + E3 | Community | | `sent` | [resend.email.sent](/verify/resend/resend.email.sent) v1.0.0 | The sent level proves the email.sent event of this email. It does not prove that the recipient mail server accepted the message. This level needs the email.sent webhook. | E2 + E3 | Community | ## What is the Resend lifecycle? ### Which states can a `resend.email` be in? | State | Class | Verdict | Meaning | Source | | --- | --- | --- | --- | --- | | `queued` | transitional | PENDING | Resend accepted the message and holds it in its queue. | [resend.openapi](https://raw.githubusercontent.com/resend/resend-openapi/main/resend.yaml) | | `scheduled` | transitional | PENDING | The message waits for its scheduled send time. | [resend.openapi](https://raw.githubusercontent.com/resend/resend-openapi/main/resend.yaml) | | `sent` | transitional | PENDING | Resend handed the message to its sending infrastructure and attempts delivery. | [resend.openapi](https://raw.githubusercontent.com/resend/resend-openapi/main/resend.yaml) | | `delivery_delayed` | transitional | PENDING | The recipient mail server did not accept the message yet. Resend retries. | [resend.openapi](https://raw.githubusercontent.com/resend/resend-openapi/main/resend.yaml) | | `delivered` | terminal success | VERIFIED | The recipient mail server accepted the message. | [resend.openapi](https://raw.githubusercontent.com/resend/resend-openapi/main/resend.yaml) | | `opened` | terminal success | VERIFIED | The recipient opened the message. Delivery happened before. | [resend.openapi](https://raw.githubusercontent.com/resend/resend-openapi/main/resend.yaml) | | `clicked` | terminal success | VERIFIED | The recipient clicked a link in the message. Delivery happened before. | [resend.openapi](https://raw.githubusercontent.com/resend/resend-openapi/main/resend.yaml) | | `complained` | terminal neutral | FAILED | The message was delivered, and the recipient marked it as spam. | [resend.openapi](https://raw.githubusercontent.com/resend/resend-openapi/main/resend.yaml) | | `bounced` | terminal failure | FAILED | The recipient mail server rejected the message. | [resend.openapi](https://raw.githubusercontent.com/resend/resend-openapi/main/resend.yaml) | | `failed` | terminal failure | FAILED | Resend could not send the message. | [resend.openapi](https://raw.githubusercontent.com/resend/resend-openapi/main/resend.yaml) | | `suppressed` | terminal failure | FAILED | Resend suppressed the message because the recipient address is on a suppression list. | [resend.openapi](https://raw.githubusercontent.com/resend/resend-openapi/main/resend.yaml) | | `canceled` | terminal neutral | FAILED | The schedule of the message was canceled before the send. | [resend.openapi](https://raw.githubusercontent.com/resend/resend-openapi/main/resend.yaml) | In `resend.email` under provider API version `1.5.1`, `delivered`, `opened` and `clicked` are the only states that mean terminal success. Every other state gives PENDING, FAILED, or UNVERIFIABLE. Source: https://raw.githubusercontent.com/resend/resend-openapi/main/resend.yaml (retrieved 2026-09-05) ## How does Provely tie the evidence to this exact operation? A matching state that already existed must not verify. Every contract names the [correlation](/glossary/correlation) keys that bind the evidence to the operation, and the [idempotency](/glossary/idempotency) key that stops a duplicate side effect. | Strategy | Assurance | Keys | Required | Window | | --- | --- | --- | --- | --- | | `resource_id` | strong | email_id from `$action.result.id` | yes | none | | `idempotency_key` | strong | idempotency_key from `$operation.id` | no | none | | `fingerprint` | weak | to from `$input.to`; subject from `$input.subject` | no | 600000 ms | ## Which evidence channels does the skill read? The runtime prefers the channel that is more independent from the action path. Read the [evidence level](/glossary/evidence-level) definition. An [acknowledgement](/glossary/acknowledgement) from Resend is E1 and never terminal success. | Channel | Level | Independence | Verifier | Deterministic | Typical latency | | --- | --- | --- | --- | --- | --- | | `email_action_response` | E1 | same response | `action_result` | yes | not stated | | `bounced_events` | E3 | provider event | `webhook` | no | 5000 ms | | `delivered_events` | E3 | provider event | `webhook` | no | 5000 ms | | `sent_events` | E3 | provider event | `webhook` | no | 5000 ms | | `sent_events_by_intent` | E3 | provider event | `webhook` | no | 5000 ms | | `email_readback` | E2 | provider readback | `http` | yes | 300 ms | ## Which ways can a Resend action look done and not be? | Contract | Case | Rule | Verdict | | --- | --- | --- | --- | | [resend.email.accepted](/verify/resend/resend.email.accepted) | wrong subject | The message went to a different recipient. | CONTRADICTED | | [resend.email.accepted](/verify/resend/resend.email.accepted) | pre existing state | The provider record is older than the operation. It proves nothing. | CONTRADICTED | | [resend.email.accepted](/verify/resend/resend.email.accepted) | partial completion | The record lists more than one recipient. This contract proves the outcome for one recipient. Use one operation per recipient. | CONTRADICTED | | [resend.email.accepted](/verify/resend/resend.email.accepted) | duplicate side effect | Resend sent more than one email for this recipient and subject since the operation started. Do not retry. | CONTRADICTED | | [resend.email.accepted](/verify/resend/resend.email.accepted) | observed state | The provider reports that the message failed, bounced, or was suppressed. | FAILED | | [resend.email.accepted](/verify/resend/resend.email.accepted) | observed state | The schedule of the message was canceled. The provider will not send it. | CONTRADICTED | | [resend.email.bounced](/verify/resend/resend.email.bounced) | wrong subject | The message went to a different recipient. | CONTRADICTED | | [resend.email.bounced](/verify/resend/resend.email.bounced) | pre existing state | The provider record is older than the operation. It proves nothing. | CONTRADICTED | | [resend.email.bounced](/verify/resend/resend.email.bounced) | partial completion | The record lists more than one recipient. This contract proves the outcome for one recipient. Use one operation per recipient. | CONTRADICTED | | [resend.email.bounced](/verify/resend/resend.email.bounced) | duplicate side effect | Resend sent more than one email for this recipient and subject since the operation started. Do not retry. | CONTRADICTED | | [resend.email.bounced](/verify/resend/resend.email.bounced) | observed state | The provider reports that the message failed, bounced, or was suppressed. | FAILED | | [resend.email.bounced](/verify/resend/resend.email.bounced) | observed state | The message is on the way. The runtime observes again later. | PENDING | | [resend.email.bounced](/verify/resend/resend.email.bounced) | observed state | The schedule of the message was canceled. The provider will not send it. | CONTRADICTED | | [resend.email.bounced](/verify/resend/resend.email.bounced) | observed state | The recipient mail server accepted the message. It did not bounce. | CONTRADICTED | | [resend.email.delivered](/verify/resend/resend.email.delivered) | wrong subject | The message went to a different recipient. | CONTRADICTED | | [resend.email.delivered](/verify/resend/resend.email.delivered) | pre existing state | The provider record is older than the operation. It proves nothing. | CONTRADICTED | | [resend.email.delivered](/verify/resend/resend.email.delivered) | partial completion | The record lists more than one recipient. This contract proves the outcome for one recipient. Use one operation per recipient. | CONTRADICTED | | [resend.email.delivered](/verify/resend/resend.email.delivered) | duplicate side effect | Resend sent more than one email for this recipient and subject since the operation started. Do not retry. | CONTRADICTED | | [resend.email.delivered](/verify/resend/resend.email.delivered) | observed state | The provider reports that the message failed, bounced, or was suppressed. | FAILED | | [resend.email.delivered](/verify/resend/resend.email.delivered) | observed state | The message is on the way. The runtime observes again later. | PENDING | | [resend.email.delivered](/verify/resend/resend.email.delivered) | observed state | The schedule of the message was canceled. The provider will not send it. | CONTRADICTED | | [resend.email.delivered](/verify/resend/resend.email.delivered) | observed state | The recipient marked the message as spam. The record no longer states the delivery state. | UNVERIFIABLE | | [resend.email.sent](/verify/resend/resend.email.sent) | wrong subject | The message went to a different recipient. | CONTRADICTED | | [resend.email.sent](/verify/resend/resend.email.sent) | pre existing state | The provider record is older than the operation. It proves nothing. | CONTRADICTED | | [resend.email.sent](/verify/resend/resend.email.sent) | partial completion | The record lists more than one recipient. This contract proves the outcome for one recipient. Use one operation per recipient. | CONTRADICTED | | [resend.email.sent](/verify/resend/resend.email.sent) | duplicate side effect | Resend sent more than one email for this recipient and subject since the operation started. Do not retry. | CONTRADICTED | | [resend.email.sent](/verify/resend/resend.email.sent) | observed state | The provider reports that the message failed, bounced, or was suppressed. | FAILED | | [resend.email.sent](/verify/resend/resend.email.sent) | observed state | The message is on the way. The runtime observes again later. | PENDING | | [resend.email.sent](/verify/resend/resend.email.sent) | observed state | The schedule of the message was canceled. The provider will not send it. | CONTRADICTED | ## What did the last conformance run show? *The six confidence dimensions of the signed manifest.* | Dimension | Score | Maximum | | --- | --- | --- | | Documentation | 14 | 20 | | Schema alignment | 12.31 | 15 | | Lifecycle certainty | 20 | 20 | | Evidence strength | 12 | 20 | | Causal correlation | 15 | 15 | | Sandbox conformance | 9.67 | 10 | | Raw score | 82.98 | 100 | | Score after the caps | 49 | 100 | The raw score is 82.98. 2 hard caps apply, so the score is 49 and the level is Community. *The hard caps the compiler applied.* | Gate | Cap | Reason | | --- | --- | --- | | `uncertainty_caps` | 49 | 2 uncertainty records are open. The lowest cap is 49. | | `conformance_threshold` | 89 | 2 conformance cases failed. | The last conformance run on 2026-09-05T12:00:00Z passed 58 of 60 cases with 0 critical false VERIFIED. One critical false VERIFIED rejects a skill. *The conformance result by case class.* | Case class | Passed | Total | | --- | --- | --- | | duplicate side effect | 4 | 4 | | error after execution | 4 | 4 | | error before execution | 4 | 4 | | evidence unavailable | 4 | 4 | | idempotent retry | 3 | 4 | | pre existing state | 4 | 4 | | stale readback | 4 | 4 | | still transitional | 4 | 4 | | terminal failure | 4 | 4 | | terminal success | 3 | 4 | | timeout after commit | 4 | 4 | | version mismatch | 4 | 4 | | webhook duplicate | 4 | 4 | | webhook out of order | 4 | 4 | | wrong subject | 4 | 4 | The conformance artifact digest is `9e6ec913dfe29cd9`. The harness signs the run, so a reader can check that these numbers come from that run. ## What remains uncertain? **Open questions remain. 2 uncertainty records are open. The lowest cap is 49. The published manifest states the cap and its reason. The questions themselves stay in the compiler review bundle, which no customer receives.** > This is why the level is Community and not higher. Unknown means unknown. The compiler does not infer an undocumented rule. ## Where do these facts come from? Every claim above cites a source assertion in the skill provenance. The compiler records the source, its hash, and the retrieval date. A page never states a provider rule without one. | Source | Kind | Retrieved | Excerpt | | --- | --- | --- | --- | | [resend.docs.idempotency](https://resend.com/docs/dashboard/emails/idempotency-keys) | docs | 2026-09-05 | authored | | [resend.docs.webhooks](https://resend.com/docs/dashboard/webhooks/introduction) | docs | 2026-09-05 | authored | | [resend.openapi](https://raw.githubusercontent.com/resend/resend-openapi/main/resend.yaml) | openapi | 2026-09-05 | trimmed | ## How do I verify a Resend action? ### Verify a Resend action with Provely 1. **Begin the operation.** Call `begin` with the contract `resend.email.accepted` and the input. Keep the operation id and the idempotency key. 2. **Make the Resend call you make today.** Send the `Idempotency-Key` header with the key that `begin` returned. A retry then cannot create a second side effect. 3. **Submit the acknowledgement.** Call `action_result` with the Resend response. This is evidence level E1. It is not completion. 4. **Verify.** Call `verify`. The runtime reads `email_action_response`, `bounced_events`, `delivered_events`, `sent_events`, `sent_events_by_intent` and `email_readback` and evaluates the contract. 5. **Report the verdict exactly as returned.** VERIFIED comes with a signed receipt. PENDING comes with the operation id. CONTRADICTED and UNVERIFIABLE are not success. ## Questions developers ask ### Does the `accepted` level prove the `sent` level? No. The accepted level proves that Resend holds an email record for the request. It does not prove that the message left the provider. The sent level proves the email.sent event of this email. It does not prove that the recipient mail server accepted the message. This level needs the email.sent webhook. Use `resend.email.sent` to prove `sent`. ### What does the agent say while Resend reports `queued`, `scheduled`, `sent` and `delivery_delayed`? It says: "The action is accepted but not yet verified. Operation: ." The verdict is PENDING. The runtime observes again on the contract timing policy. ### Which Resend API versions does the skill support? `1.5.1`. An operation on another version returns UNVERIFIABLE with the reason `version_unsupported`. The runtime never guesses. ### Does Provely need write access to Resend? No. The agent keeps its write key. The verifier reads with a separate read-only credential where Resend permits it, and it never shares that credential with the agent. ## Read next - [Read the resend.email.accepted contract](https://provely.sh/verify/resend/resend.email.accepted) - [Read the resend.email.bounced contract](https://provely.sh/verify/resend/resend.email.bounced) - [Read the resend.email.delivered contract](https://provely.sh/verify/resend/resend.email.delivered) - [Read the resend.email.sent contract](https://provely.sh/verify/resend/resend.email.sent) - [Read the Shopify Admin API verification page](https://provely.sh/verify/shopify) - [Read the Stripe verification page](https://provely.sh/verify/stripe) - [See every verified service](https://provely.sh/verify) - [Verify Resend actions from Claude Code](https://provely.sh/agents/claude-code) - [Verify Resend actions from Cursor](https://provely.sh/agents/cursor) - [See every agent integration](https://provely.sh/agents) - [Open the quick start](https://provely.sh/docs/quick-start) - [Read the completion level definition](https://provely.sh/glossary/completion-level)