> ## Documentation Index > Fetch the complete documentation index at: https://docs.x402layer.cc/llms.txt > Use this file to discover all available pages before exploring further. # Get the update policy > Who decides WHEN this pod takes our updates. By default we do: the pod polls every six hours and applies whatever we answer, restarting its gateway for about forty seconds. That is right for a pod somebody runs for themselves and wrong for pods run on behalf of customers, whose agents would all restart at a moment their operator did not choose. `manual` makes us keep answering with the version the pod already has, so it never updates itself. Apply the update yourself with `POST /actions {"action":"update"}`. **The hold expires after 30 days.** Security fixes ride these bundles, so an indefinitely pinned pod stops being a scheduling choice and becomes an unpatched machine. `hold_expires_at` always names the date. ## OpenAPI ````yaml /api-reference/openapi.json get /pods/v1/pods/{id}/updates openapi: 3.1.0 info: title: x402 Singularity Layer API description: >- OpenAPI-backed reference for marketplace discovery, payment routes, webhooks, wallet-first auth, agent endpoints, and ERC-8004 flows. version: 1.0.0 servers: - url: https://api.x402layer.cc security: [] tags: - name: Marketplace description: Public discovery and listing lookup - name: Public Endpoints description: Public endpoint metadata and hosted checkout context - name: Public Payment Links description: Hosted public payment-link lookup - name: Payments description: Hosted x402 payment challenge routes - name: Receipts description: Signed receipt lookup and verification helpers - name: Ratings description: Public listing ratings and authenticated rating actions - name: Webhooks description: Seller webhook management API - name: Agent Auth description: Wallet-first challenge and verification routes - name: Agent Endpoints description: Create, read, top up, and delete agent endpoints - name: ERC-8004 description: Agent registry and registration lifecycle routes - name: Marketplace Agents description: Public ERC-8004 marketplace discovery routes - name: Compute Catalog description: Compute plans, regions, and OS catalog - name: Compute Instances description: Provision, inspect, extend, and destroy compute instances - name: Compute API Keys description: API keys for compute agent access - name: Fundraiser Campaigns description: List, view, create, and edit fundraiser campaigns - name: Fundraiser Contributions description: Record and list campaign contributions - name: Fundraiser Comments description: Campaign comment threads - name: Fundraiser Media description: Campaign image uploads and OG images - name: Enterprise description: >- Enterprise partner configuration, endpoint listing, revenue stats, and transaction ledger - name: Staking description: Agentic $SGL staking - name: SGL Grid description: >- Decentralized, confidential, OpenAI-compatible inference served by attested TEE nodes. - name: Compute Credits description: Prepaid USDC credit balance shared across Machines and Grid. - name: Agent Pods description: >- Deploy and manage hosted agents (Agent Pods), plus the pod's OpenAI-compatible adapter for external clients. - name: Agent Pods API description: >- The programmatic `/pods/v1` surface: create, drive and destroy Agent Pods with a single `X-API-Key`. Distinct from the Agent Pods dashboard routes, which expect a wallet signature or a browser session. paths: /pods/v1/pods/{id}/updates: get: tags: - Agent Pods API summary: Get the update policy description: >- Who decides WHEN this pod takes our updates. By default we do: the pod polls every six hours and applies whatever we answer, restarting its gateway for about forty seconds. That is right for a pod somebody runs for themselves and wrong for pods run on behalf of customers, whose agents would all restart at a moment their operator did not choose. `manual` makes us keep answering with the version the pod already has, so it never updates itself. Apply the update yourself with `POST /actions {"action":"update"}`. **The hold expires after 30 days.** Security fixes ride these bundles, so an indefinitely pinned pod stops being a scheduling choice and becomes an unpatched machine. `hold_expires_at` always names the date. operationId: podsV1UpdatesGet parameters: - name: id in: path required: true schema: type: string format: uuid description: Pod id, as returned by create/list. responses: '200': description: The pod's update policy. headers: x-request-id: schema: type: string content: application/json: schema: type: object properties: updates: type: object properties: mode: type: string enum: - auto - manual serving_version: type: string description: >- The version we are telling the pod to be on. In auto this is simply the latest. latest_version: type: string update_available: type: boolean description: >- True only when a hold is actually keeping a release back. hold_expires_at: type: string nullable: true description: >- The date the pod updates itself regardless. Null in auto. hold_expired: type: boolean description: >- True once the 30-day ceiling has passed: still manual, no longer holding anything. security: - podsApiKey: [] components: securitySchemes: podsApiKey: type: apiKey in: header name: X-API-Key description: >- A compute API key (`x402c_...`). Mint one in the dashboard under Settings -> API Keys. This is the ONLY auth `/pods/v1/*` accepts - wallet signatures are bound to method+path+body and do not survive the internal hop, so signature callers must use the dashboard routes instead. Two extra scopes gate the dangerous powers: `pods:wallet:write` (pod wallet money, backup passphrase) and `pods:control:write` (connectors, full-power control socket). ````