# Outcome feedback and reviewed refunds

Authenticated customers can submit delivery or bounce evidence with `POST /v1/outcomes` and retrieve it with `GET /v1/outcomes/{id}`. Supported outcomes are `delivered`, `invalid_recipient`, `temporary_failure`, `policy_rejection`, and `unknown`. Use an `Idempotency-Key`; provider event IDs are also unique within a tenant.

Outcome records are tenant-scoped and are removed when the associated address-level verification reaches its retention deadline. Raw SMTP transcripts are not accepted.

## Initial refund policy

An invalid-recipient report is potentially eligible only when HonestMX returned `deliverable`, the failure was observed after the check and within 72 hours, and no refund exists. Customer assertions never trigger an automatic credit. They enter `pending_review`; an operator must validate the evidence and approve or reject it. Approval, the one-unit balance credit and the explicit `refund` ledger row commit atomically, so a retry cannot pay twice.

Policy/content rejection, reputation blocks, temporary failures, quota problems, customer cancellation and duplicate reports are not invalid-recipient refunds. Future trusted ESP integrations may automate approval only after their signed event authentication and outcome mapping are reviewed.