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 for the request binding that returns the same operation after a lost response.