Why actions exist
Financial operations — placing trades, creating accounts, transferring funds — carry real consequences. The action model ensures:- Every mutating operation requires explicit approval
- You can review what will happen before it executes
- Actions are auditable with full history
- Integrations can propose operations that a human approves
The action lifecycle
| Status | Description |
|---|---|
pending | Action created, waiting for approval |
approved | User approved the action |
rejected | User rejected the action |
executed | Action was approved and successfully executed |
expired | Action expired before a decision was made |
Create an action
Actions are created automatically when you call mutating endpoints like paper trading. You can also create custom actions:Check action status
Poll the action to check whether it’s been approved:List and filter actions
View all actions with optional filters:Approve or reject
Submit an approval decision programmatically:approval_url returned when the action was created.
Use idempotency keys
Prevent duplicate actions when retrying:409 Conflict is returned if the key matches but the parameters differ.
What’s next
Paper trading
See actions in practice with paper trades.
Idempotency
Prevent duplicate operations safely.