Skip to main content
Automation definitions are app-scoped and reusable. Attachments activate those definitions for individual wallets.

List automations

List all definitions with GET /v1/wallet_automations. Pass wallet_id to return only automations attached to one wallet. Wallet create, get, and list responses can also include an automations array. Each entry contains the automation id and an enabled value that reflects both the definition and attachment state. The Node SDK and Python examples initialize reusable clients here. The remaining examples on this page reuse those clients.

Update an automation

PATCH /v1/wallet_automations/{automation_id} can update name, config, enabled, or owner_id. Fields omitted from the request remain unchanged. Setting name or owner_id to null clears that field. The existing owner must authorize updates to an owned automation.
Updating config changes the trigger and action for every attached wallet. Create a separate automation when only some wallets should adopt the new behavior.

Pause or resume an automation

Disabling an automation pauses it for every attached wallet. Attachments remain in place and resume when the automation is enabled again. Automation responses represent this state as status: "enabled" | "disabled". Update requests use the boolean enabled field.

Matching precedence

A wallet can have multiple attached automations. Privy evaluates enabled attachments from oldest to newest and runs only the first matching automation. Privy does not try a lower-priority match if the selected automation fails. Use non-overlapping asset filters when every route must be unambiguous. If filters intentionally overlap, attach the highest-priority automation first. Attaching an automation that is already attached updates the existing attachment and preserves its priority. Detaching and later reattaching creates a new attachment that is evaluated after older attachments.

Update attachment parameters

Call the attach endpoint again with the existing automation ID to change its per-wallet parameters. For a swap automation, this updates destination_address without creating a duplicate attachment. The request’s single params object applies to every automation ID. Batch together only automations that accept the same parameters.

Detach from a wallet

Detaching stops selected automations for one wallet without changing their other attachments. Detach requests are all or nothing. If any requested automation is not attached to the wallet, the request fails without detaching the others.
A successful private-key or seed-phrase export also removes all automation attachments from that wallet. The exported wallet cannot receive new automation attachments.

Delete an automation

Deleting an automation permanently removes its definition and all attachments. Existing execution and wallet action records remain, but a deleted attachment can no longer identify its automation through the execution list response. Persist the IDs from submitted webhooks when long-term correlation is required. Use disable when the automation might resume. Use detach to stop it for selected wallets. Delete only when the definition is no longer needed.

Advanced: automation ownership

Set owner_id during creation or update to assign a key quorum as the automation owner. The existing owner must authorize changing or clearing owner_id. The owner protects the shared definition. The wallet owner separately controls whether that definition is attached to their wallet.

Limits

  • Imported wallets and wallets previously exported from Privy cannot receive automation attachments.
  • An attach or detach request accepts up to 20 automation IDs.
  • An include or exclude filter accepts up to 20 asset specifications in an API request.
  • A wallet can have up to 100 automation attachments.
  • List endpoints accept limit values from 1 through 100 and default to 25.
See the wallet automation API reference for request and response schemas.