Guides

Verification results

Every verification that runs returns a result and a signed receipt. Here’s what each result means, how to tell “couldn’t check” apart from “didn’t happen,” and how to wire outcomes into recovery.

The five results

result	Meaning	What to do
`verified`	Every postcondition passed.	The action completed correctly. Store the receipt and move on.
`incomplete`	The action isn't in the system of record.	The work didn't happen. Reopen, retry, or escalate.
`duplicated`	The action happened more than once.	Reconcile or compensate the duplicate.
`mismatched`	The action exists but a field disagrees (amount, customer, status...).	Route to review, the claim doesn't match reality.
`policy_failed`	A required policy or approval step was missing.	Route per your policy before treating it as done.

Postconditions: passed, failed, skipped

The receipt lists every postcondition with a status. passed and failed are self-explanatory. skipped is the important one: Postcept couldn’t make the check, an email it couldn’t resolve, a duplicate check with no correlatable id. A skipped check is never counted as a pass. It means “not confirmed,” so a result is only verified when the checks that matter actually ran and passed.

When a verification can’t run

A well-formed request returns 201 with a result. Other responses tell you to retry, fix the request, or check billing.

Status	Meaning
`201`	Verification ran. Read result.
`200`	Idempotent replay, the original verification for a repeated Idempotency-Key.
`401`	Missing or invalid API key.
`402`	Free-trial allowance reached, subscribe to keep verifying.
`422`	Malformed request body.
`429`	Rate limited. Back off and honor Retry-After.
`503`	The system of record couldn't be reached, retryable.

The one to handle deliberately is 503. It means the system of record was unreachable, not that the action failed. Postcept refuses to record a false incomplete when it couldn’t actually check, so a 503 is your signal to retry with backoff, not to start recovery.

Recovery

Treat verified as done. Route incomplete, duplicated, mismatched, and policy_failed into your recovery workflow, human review, retry reconciliation, or compensation. Postcept surfaces these for you in the recovery queue, and the signed receipt is the evidence of exactly what was and wasn’t confirmed.

Idempotency

Send an Idempotency-Key header, the operation id is a natural choice. A repeat with the same key returns the original verification (200) instead of re-running, so a retry after a network blip never double-verifies or double-charges.

Idempotency-Key header

curl https://api.postcept.com/v1/verifications \
  -H "Authorization: Bearer pcpt_sk_..." \
  -H "Idempotency-Key: op_refund_8F31" \
  -H "Content-Type: application/json" \
  -d '{ "operation_id": "op_refund_8F31", "agent_id": "...", "claim": { ... } }'

Quickstart Receipt format API reference

Want the mechanics behind the checks? See postcondition verification.