> ## Documentation Index
> Fetch the complete documentation index at: https://docs.leapfinancial.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Operation lifecycle

> Statuses an operation can take after creation, and the webhooks you receive for each transition

## Overview

When a user completes a transfer in a widget, RaaS Widgets creates an **operation**. From that moment you track progress with the Partner API field `status` and the matching `operation.*` webhooks.

You do not need to model corridor-level processing steps. Subscribe to create and terminal events, and poll [Operations](/raas-widgets/ops/operations) if you need the current `status` between deliveries.

## Status values

| Status       | Meaning                                                                              | Terminal? |
| ------------ | ------------------------------------------------------------------------------------ | --------- |
| `created`    | Operation persisted; identity, limits, funding, and submission still in progress     | No        |
| `processing` | Transfer accepted by the corridor; funds are in flight / awaiting settlement         | No        |
| `completed`  | Transfer settled successfully                                                        | Yes       |
| `failed`     | Transfer failed permanently                                                          | Yes       |
| `cancelled`  | Operation cancelled (user, compliance, funding expiry/rejection, or corridor cancel) | Yes       |

<Note>
  There is no `operation.expired` webhook. Funding expiry and similar outcomes map to **`cancelled`**.
</Note>

## Status graph

```mermaid theme={null}
stateDiagram-v2
    [*] --> created: operation.created

    created --> processing: Corridor accepts transfer
    created --> cancelled: Cancel / reject before accept
    created --> failed: Failure before accept

    processing --> completed: Settled
    processing --> failed: Execution failed
    processing --> cancelled: Cancelled while in flight

    completed --> [*]
    failed --> [*]
    cancelled --> [*]
```

### Typical happy path

1. Widget creates the operation → `status: created` → webhook `operation.created`
2. Corridor accepts the transfer → `status: processing` (no dedicated webhook; poll if needed)
3. Corridor settles → `status: completed` → webhook `operation.completed`

### Failure and cancel paths

From `created` or `processing`, the operation can end in:

* `failed` → `operation.failed`
* `cancelled` → `operation.cancelled`

<Warning>
  If you reserve balances or locks on `operation.created`, reverse them on `operation.failed` or `operation.cancelled`. Treat only `operation.completed` as final success for fulfillment.
</Warning>

## Webhooks vs API

| Moment                    | Webhook               | `status` on `GET /partner/operations/:id` |
| ------------------------- | --------------------- | ----------------------------------------- |
| User commits the transfer | `operation.created`   | `created`                                 |
| Corridor accepts          | —                     | `processing`                              |
| Settled                   | `operation.completed` | `completed`                               |
| Failed                    | `operation.failed`    | `failed`                                  |
| Cancelled                 | `operation.cancelled` | `cancelled`                               |

Payload shapes: [Webhook events](/raas-widgets/webhooks/events).

<Tip>
  Handlers should be idempotent. Retries can redeliver the same terminal event. Key on `operationId` + event type.
</Tip>

## Correlation fields

| Field           | When present                                                      |
| --------------- | ----------------------------------------------------------------- |
| `operationId`   | Always                                                            |
| `linkId`        | Always (magic link that created the op)                           |
| `referenceId`   | Often on create/cancel paths — your end-user id                   |
| `requestId`     | When the op fulfills a money request (Request API / fund-request) |
| `originationId` | When the op comes from a deferred payout claim                    |

Use `requestId` to tie settlement webhooks back to the original money request — see [Request money lifecycle](/raas-widgets/request-api/lifecycle).

## Next steps

<CardGroup cols={2}>
  <Card title="Webhook events" icon="bell" href="/raas-widgets/webhooks/events">
    Full payload reference for `operation.*`.
  </Card>

  <Card title="Operations API" icon="list" href="/raas-widgets/ops/operations">
    List and fetch operations for reconciliation.
  </Card>

  <Card title="Request money lifecycle" icon="arrows-split-up-and-left" href="/raas-widgets/request-api/lifecycle">
    How Request API and fund-request links become operations.
  </Card>

  <Card title="Webhooks overview" icon="webhook" href="/raas-widgets/webhooks/overview">
    Delivery, retries, and configuration.
  </Card>
</CardGroup>