---
search:
  tags:
    - Actions
    - POST
seo:
  description: >-
    Repeat the write of an unknown effect under the same provider… Reference for
    the POST /api/v2/actions/effects/{id}/replay endpoint in the Anlyon API.
sidebar:
  label: Replay a lost write under the same identity
  badge: POST
title: Replay a lost write under the same identity
type: openapi-operation
---
Repeat the write of an `unknown` effect under the same provider identity, for adapters that declare `sameKeyReplay` backed by a provider idempotency key (`stripe.refund` and `resend.email_send`, each within its 24-hour window). `github.file_update` does not offer replay: GitHub has no idempotency key, and the blob-SHA precondition cannot tell a restored file from an unwritten one. A declared action never offers replay either, because it sends no provider idempotency key. A replay is a write and passes every control a first dispatch passes: the reviewed binding and preview expiry, the approval, the action version that would run now, the halt switch, the requesting credential's authority, current policy and dependencies. Every refusal has one shape: `409` with code `REPLAY_REFUSED`, the reason in `details.reason` (`replay_unsupported`, `not_unknown`, `replay_window_passed`, `credential_unavailable`, `allowance_released`, `write_in_flight`, or the dispatch control that failed, such as `policy_denies` or `preview_expired`) and the effect's current outcome in `details.outcome`. A refusal is recorded in the effect's evidence, sends nothing and changes nothing else. An admitted replay that fails (never sent, or refused by the provider) describes that attempt, not the original write: the effect stays `unknown` with its allowance held. Only the provider's own record of the operation in a failed state settles it `failed`. It never creates a second effect.

`POST /api/v2/actions/effects/{id}/replay`