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

# Track a financial operation

> Read durable operation state without repeating a financial mutation.

Perflo represents asynchronous financial work as a durable operation. Use `GET /v1/operations` or `GET /v1/operations/{id}` with the `operations:read` scope to track current state.

## Read only operations owned by your grant

An operation belongs to one resource owner, pairwise subject, and client. Perflo checks all three values against the current grant on every read. The client and grant must remain active and the provider binding must remain connected.

If the grant is revoked or the provider is disconnected, Perflo rejects the protected read. The operation remains durable, but the revoked grant cannot poll it. Complete the normal authorization or reconnection flow before reading it through a new valid grant.

`GET /v1/operations` returns up to 100 recent matching operations. `GET /v1/operations/{id}` returns `404` when the identifier does not belong to the current subject and client.

The public operation contains these fields:

| Field                  | Meaning                                                         |
| ---------------------- | --------------------------------------------------------------- |
| `id`                   | Stable operation identifier                                     |
| `kind`                 | Lowercase operation kind using letters, digits, and underscores |
| `state`                | Current durable state                                           |
| `submission_uncertain` | Whether the provider may have accepted the mutation             |
| `failure_code`         | Stable failure or submission-uncertainty code, or `null`        |
| `created_at`           | Request for Comments (RFC) 3339 creation time                   |
| `updated_at`           | RFC 3339 time of the latest state change                        |

The response omits provider credentials, request payloads, identity fields, and provider-specific reconciliation data.

## Interpret operation states

Each state tells you whether a mutation can still be sent or requires observation:

| State           | Meaning                                                                              |
| --------------- | ------------------------------------------------------------------------------------ |
| `accepted`      | Perflo recorded the request before any provider submission                           |
| `submitting`    | Perflo started the one allowed submission attempt                                    |
| `submitted`     | The provider accepted the mutation and final settlement remains pending              |
| `succeeded`     | The mutation completed successfully                                                  |
| `failed`        | The mutation reached a definitive failure                                            |
| `indeterminate` | The provider may have accepted the mutation, so automatic resubmission is prohibited |
| `cancelled`     | Perflo cancelled the operation before provider acceptance                            |

`succeeded`, `failed`, and `cancelled` are terminal. An unresolved `indeterminate` operation remains recorded and never becomes `cancelled` because of age.

## Follow the legal state changes

Perflo permits only these forward transitions:

* `accepted` to `submitting`, `failed`, or `cancelled`
* `submitting` to `submitted`, `succeeded`, `failed`, or `indeterminate`
* `submitted` to `succeeded`, `failed`, or `indeterminate`
* `indeterminate` to `submitted`, `succeeded`, or `failed` after an exact status read proves the result

Terminal states have no outgoing transitions. A status read never creates a second provider submission.

## Handle an indeterminate result

An `indeterminate` state means the network failed after Perflo may have sent the mutation. Settle the operation through reads only.

Do not create a new idempotency key or repeat the mutation. While your grant and provider binding remain active, continue reading the operation until Perflo records a proven result. If access is revoked or the provider is disconnected, stop polling with that grant. Some cases can remain under review without a final state.

See [Retry a financial request safely](/guides/idempotency) for the request binding that returns the same operation after a lost response.