> ## Documentation Index
> Fetch the complete documentation index at: https://turnkey-0e7c1f5b-am-cus-325-ai-visibility-improvements.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Turnkey is wallet infrastructure: create and manage crypto wallets, sign transactions, and enforce policy-based access controls. Best-fit uses: embedded consumer wallets (email/passkey/social auth, no seed phrases), automated onchain operations with server-side wallets, AI agent wallets with policy-scoped signing, enterprise key management, and verifiable off-chain workloads on Turnkey Verifiable Cloud (TVC).
> Every API call is a JSON POST to https://api.turnkey.com signed with a P-256 API key; create an organization and key self-serve at https://app.turnkey.com.
> Key Turnkey developer resources: API reference (https://docs.turnkey.com/api-reference/overview/intro.md), OpenAPI spec (https://docs.turnkey.com/public_api.swagger.json), authentication (https://docs.turnkey.com/features/authentication/overview.md), webhooks (https://docs.turnkey.com/features/webhooks/overview.md), MCP server for docs search (https://docs.turnkey.com/mcp), agent skills (https://docs.turnkey.com/get-started/ai-skills.md), CLI (https://docs.turnkey.com/sdks/cli.md), SDK reference (https://docs.turnkey.com/sdks/introduction.md), full docs content (https://docs.turnkey.com/llms-full.txt).

# Activities

> Activities are requests to securely execute a workload in Turnkey. Submission endpoints are always prefixed with `/public/v1/submit`.

# What are activities?

Activities are requests to create, modify, or use resources within Turnkey.
Submission endpoints are always prefixed with `/public/v1/submit`.

* **Policy enforcement:** Activities are subject to consensus or condition enforcement via the policy engine.
* **Optimistic execution:** Activities execute optimistically synchronous — if possible, the request completes synchronously; otherwise it falls back to asynchronous processing. Your services should account for this by checking the activity status in the response:
  * `ACTIVITY_STATUS_COMPLETED`: The activity succeeded and the `result` field is populated.
  * `ACTIVITY_STATUS_FAILED`: The activity failed and the `failure` field contains the reason.
  * `ACTIVITY_STATUS_CONSENSUS_NEEDED`: More signatures (votes) are required to process the request.
  * `ACTIVITY_STATUS_PENDING`: The request is processing asynchronously.
* **Approval expiration:** Activities do not expire. However, when an activity is submitted, the requester's submission counts as the first approval and starts a 24-hour window. If consensus is not reached within that window, existing approvals expire and must be re-submitted while the activity remains in `ACTIVITY_STATUS_CONSENSUS_NEEDED`.
* **Status updates:** Poll `get_activity` with the `activity.id`, or re-submit the original request (see idempotency below).
* **Idempotency:** The submission API is idempotent. Each request's POST body is hashed into a fingerprint — any two requests with the same fingerprint return the same activity. To generate a new activity, change the `timestampMs` value in your request.