Follow and recover an operation

An operation tracks CRISP executing a command. An order tracks venue fills and cancellation. A succeeded limit-order command can leave an open, unfilled order.

Before you start: retain the authorized external user ID and the exact original intent. These reads use your existing trading access. HTTP tabs omit signing headers.

You received a command ID

const result = await crisp.getOperation(
  'example:user-123',
  '00000000-0000-0000-0000-000000000001',
);

This account-scoped read consults CRISP's durable ledger. It does not submit, sign, reclaim or retry a command, or call the trading venue.

waitForOperation stops on succeeded, failed or ambiguous. Inspect the result. Its timeout only stops waiting; it does not cancel a trade.

The initial response was lost

Use the intent saved before submission:

const result = await crisp.recoverOrder(
  'example:user-123',
  'order-buy-intent-001',
);

Replace the example key with the original saved key, not a freshly generated one. recoverOrder is a single read. If it returns pending state, use waitForOperation with the returned operation ID, or follow realtime updates. It does not wait automatically or place an order.

Kinds: order.place, order.cancel, position.redeem. Use recoverOperation(user, kind, originalKey) for any of these kinds. Successful redemption recovery includes data.operation.redemption with the transaction hash, completed count and condition IDs. Pending/ambiguous operations return null for this result, not a fabricated successful redemption.

A 404 means no command is visible for this account yet. The initial HTTP request may still be in flight. It does not authorize creating a replacement intent. Replaying the original POST with the exact same body and key remains supported. Never change the body/key to bypass ambiguity.

CrispApiError exposes status, code, requestId and retryAfterMs. A CrispTransportError includes malformed/lost responses: a mutation may already have been accepted. Retain the original intent and request ID for support.

These reads isolate the current account generation, including after reset. Existing POST-replay integrations continue to work.

Handle errors without creating another trade

In your submit handler, catch both SDK error types and inspect error.outcomeUnknown. Persist an awaiting-confirmation UI state and recover by the original key when true. A 404 recovery read may race acceptance; retry reads with a bounded backoff and escalate unresolved cases. Do not blindly loop the original write or generate replacement keys.

Done when: the operation's outcome and affected resource are established. An ambiguous result needs reconciliation, not a success toast. See SDK error fields, findOperation and getOperation.

Withdrawals and referral payouts

Withdrawal status reads use your existing funding access. Recover a lost response with recoverWithdrawal(user, originalKey) (HTTP lookup), then use waitForWithdrawal(user, result.data.withdrawal.id, { signal }). The lookup reads the durable intent even after the HTTP replay cache expires. confirmed means the source-chain transfer to the bridge was confirmed; use transfer history to establish final destination receipt. manual_review needs reconciliation and is never success.

Referral payout reads use your referral feature access. Persist the claim ID from claim acceptance, then use waitForClaim(user, claimId, { signal }) (HTTP status). A combined claim covers multiple UTC days but has one payout ID and one total amount. The wait stops at settled or manual_review; inspect terminal and needsReview. If the claim response itself was lost, read getReferralSummary and reconcile its payout history. Do not automatically submit another claim or infer failure from a temporarily missing payout. Neither helper moves funds.