ProvelyNo. 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.
| 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 | 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 | 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 | 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 | 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 definition.
| Level | Contract | Promise | Evidence | Certification |
|---|---|---|---|---|
accepted | 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 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 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 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 |
scheduled | transitional | PENDING | The message waits for its scheduled send time. | resend.openapi |
sent | transitional | PENDING | Resend handed the message to its sending infrastructure and attempts delivery. | resend.openapi |
delivery_delayed | transitional | PENDING | The recipient mail server did not accept the message yet. Resend retries. | resend.openapi |
delivered | terminal success | VERIFIED | The recipient mail server accepted the message. | resend.openapi |
opened | terminal success | VERIFIED | The recipient opened the message. Delivery happened before. | resend.openapi |
clicked | terminal success | VERIFIED | The recipient clicked a link in the message. Delivery happened before. | resend.openapi |
complained | terminal neutral | FAILED | The message was delivered, and the recipient marked it as spam. | resend.openapi |
bounced | terminal failure | FAILED | The recipient mail server rejected the message. | resend.openapi |
failed | terminal failure | FAILED | Resend could not send the message. | resend.openapi |
suppressed | terminal failure | FAILED | Resend suppressed the message because the recipient address is on a suppression list. | resend.openapi |
canceled | terminal neutral | FAILED | The schedule of the message was canceled before the send. | resend.openapi |
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: resend.openapi · 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 keys that bind the evidence to the operation, and the 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 definition. An 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 | wrong subject | The message went to a different recipient. | CONTRADICTED |
| resend.email.accepted | pre existing state | The provider record is older than the operation. It proves nothing. | CONTRADICTED |
| 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 | 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 | observed state | The provider reports that the message failed, bounced, or was suppressed. | FAILED |
| resend.email.accepted | observed state | The schedule of the message was canceled. The provider will not send it. | CONTRADICTED |
| resend.email.bounced | wrong subject | The message went to a different recipient. | CONTRADICTED |
| resend.email.bounced | pre existing state | The provider record is older than the operation. It proves nothing. | CONTRADICTED |
| 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 | 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 | observed state | The provider reports that the message failed, bounced, or was suppressed. | FAILED |
| resend.email.bounced | observed state | The message is on the way. The runtime observes again later. | PENDING |
| resend.email.bounced | observed state | The schedule of the message was canceled. The provider will not send it. | CONTRADICTED |
| resend.email.bounced | observed state | The recipient mail server accepted the message. It did not bounce. | CONTRADICTED |
| resend.email.delivered | wrong subject | The message went to a different recipient. | CONTRADICTED |
| resend.email.delivered | pre existing state | The provider record is older than the operation. It proves nothing. | CONTRADICTED |
| 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 | 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 | observed state | The provider reports that the message failed, bounced, or was suppressed. | FAILED |
| resend.email.delivered | observed state | The message is on the way. The runtime observes again later. | PENDING |
| resend.email.delivered | observed state | The schedule of the message was canceled. The provider will not send it. | CONTRADICTED |
| resend.email.delivered | observed state | The recipient marked the message as spam. The record no longer states the delivery state. | UNVERIFIABLE |
| resend.email.sent | wrong subject | The message went to a different recipient. | CONTRADICTED |
| resend.email.sent | pre existing state | The provider record is older than the operation. It proves nothing. | CONTRADICTED |
| 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 | 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 | observed state | The provider reports that the message failed, bounced, or was suppressed. | FAILED |
| resend.email.sent | observed state | The message is on the way. The runtime observes again later. | PENDING |
| 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?
| 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.
| 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.
| 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 | docs | 2026-09-05 | authored |
| resend.docs.webhooks | docs | 2026-09-05 | authored |
| resend.openapi | openapi | 2026-09-05 | trimmed |
How do I verify a Resend action?
Verify a Resend action with Provely
- Begin the operation.Call
beginwith the contractresend.email.acceptedand the input. Keep the operation id and the idempotency key. - Make the Resend call you make today.Send the
Idempotency-Keyheader with the key thatbeginreturned. A retry then cannot create a second side effect. - Submit the acknowledgement.Call
action_resultwith the Resend response. This is evidence level E1. It is not completion. - Verify.Call
verify. The runtime readsemail_action_response,bounced_events,delivered_events,sent_events,sent_events_by_intentandemail_readbackand evaluates the contract. - 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: <id>." 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.