# Polkadot Governance API Source Fit | PubFi Discovery

> A Polkadot governance API source should match the workflow: explorer-style governance reads, official ecosystem metrics, or proposal and referendum context. PubFi Discovery compares Subscan, DotLake, and Polkassembly evidence while keeping PubFi gateway availability limited to source-specific proof.

Source: Discovery demand-led page records consumed by the public Discovery routes.
Format: text/markdown; charset=utf-8
Inclusion rule: public demand-led records must be indexable; draft/noindex records are not emitted as markdown pages.
Canonical SEO rule: the HTML page is the canonical SEO URL; this Markdown route is an agent-readable mirror.
Capability boundary: page existence does not imply provider-specific MCP endpoint tools, x402 payment route, autonomous supplier call, or supplier-payment execution flow.


URL: https://pubfi.ai/discovery/topic/polkadot-governance-api
Markdown URL: https://pubfi.ai/discovery/topic/polkadot-governance-api.md
Title: Polkadot Governance API Source Fit
Summary: A Polkadot governance API source should match the workflow: explorer-style governance reads, official ecosystem metrics, or proposal and referendum context. PubFi Discovery compares Subscan, DotLake, and Polkassembly evidence while keeping PubFi gateway availability limited to source-specific proof.
Direct answer: For Polkadot governance API work, start by separating three source classes: Subscan for indexed explorer-style governance and account data, DotLake for official aggregated Polkadot ecosystem metrics, and Polkassembly for proposal, referendum, vote, and discussion context. PubFi Discovery can compare these sources and point to Subscan gateway documentation, but it does not claim every governance source is routed through PubFi.
Answer-engine handoff:
- Canonical answer URL: https://pubfi.ai/discovery/topic/polkadot-governance-api
- Agent-readable Markdown mirror: https://pubfi.ai/discovery/topic/polkadot-governance-api.md
- Query owner URL: https://pubfi.ai/discovery/topic/polkadot-governance-api
- Safe citation boundary: request integration (Request integration); Discovery can compare Polkadot governance source fit and collect workflow demand. Subscan has PubFi gateway documentation, but DotLake API and Polkassembly are public source profiles here; this topic does not claim universal PubFi-routed governance access, autonomous execution, payment support, or answer-engine citation.
- Readback boundary: ranking and AI-citation success require Search Console, public SERP, Bing/Webmaster, Vercel, and answer-engine readbacks; this export does not claim those outcomes by itself.
Primary query: Polkadot governance API
Supporting queries: best Polkadot governance API, what API can I use for Polkadot governance data, best way for an agent to query Polkadot governance
Demand area: Polkadot governance APIs
Use case: Governance-source discovery
Best starting page: https://pubfi.ai/discovery/topic/polkadot-governance-api
Availability status: request integration (Request integration)
Status-aware CTA: Signal governance data workflow interest
Actionability: not actionable
Status explanation: Discovery can compare Polkadot governance source fit and collect workflow demand. Subscan has PubFi gateway documentation, but DotLake API and Polkassembly are public source profiles here; this topic does not claim universal PubFi-routed governance access, autonomous execution, payment support, or answer-engine citation.
Machine interest signal: agent workflow
Detail export status: public/featured-export
Related source pages:
- DotLake API: https://pubfi.ai/discovery/api/dotlake-api
- Polkassembly: https://pubfi.ai/discovery/api/polkassembly
Related category pages:
- Governance: https://pubfi.ai/discovery/category/governance
- On-chain state: https://pubfi.ai/discovery/category/on-chain-state
Related chain pages:
- Polkadot: https://pubfi.ai/discovery/chain/polkadot
Related topic pages:
- Crypto Data APIs for AI Agents: https://pubfi.ai/discovery/topic/crypto-data-api-for-ai-agents
Source evidence:
- Subscan governance API endpoint family: https://support.subscan.io/doc-360177
- Subscan API source profile: repo:apps/web/src/data/discovery-static/public-directory.json#subscan
- DotLake API OpenAPI and authentication evidence: https://api.data.parity.io/openapi.json
- DotLake API source profile: repo:apps/web/src/data/discovery-static/public-directory.json#dotlake-api
- Polkassembly API resources and rate-limit notes: https://docs.polkassembly.io/jekyll/2023-10-17-api-and-resources.html
- Polkassembly source profile: repo:apps/web/src/data/discovery-static/public-directory.json#polkassembly
- Recurring SERP and answer-engine snapshot: docs/research/discovery-demand-measurement-research-2026-06-17.md
Agent use cases:
- Governance monitoring agent: Use Subscan or Polkassembly evidence when an agent needs proposal, referendum, vote, account, or discussion context for Polkadot governance monitoring.
- Ecosystem metrics agent: Use DotLake evidence when the workflow needs aggregated Polkadot ecosystem, staking, treasury, or governance metrics behind server-side API-key handling.
- Route-planning agent: Use this topic to decide whether the task needs a PubFi-documented Subscan path, a public source profile, or a separate integration request before execution.
- Agent-readable handoff: Use the PubFi Discovery page together with /agents.md, /llms.txt, and /llms-full.txt when an agent needs a compact explanation of Polkadot governance source boundaries before choosing an API.
Comparison criteria:
- Direct answer for governance source fit: Choose the source class by task: explorer-style indexed reads, official aggregated metrics, or governance discussion and referendum context.
- Subscan fit: Subscan is the strongest starting point when the agent needs indexed Substrate account, extrinsic, staking, and governance reads and the implementation can respect upstream API-key and route limits.
- DotLake fit: DotLake is stronger for official aggregated Polkadot ecosystem metrics, but its OpenAPI describes Bearer API-key authentication, so browser-only or unauthenticated agent use is not the right assumption.
- Polkassembly fit: Polkassembly is stronger for proposal, referendum, vote, and discussion context, with public API documentation and rate-limit cautions that matter for high-volume agent workflows.
- Provider-by-workflow shortlist: Use Subscan for indexed explorer-style governance and account reads, DotLake for official aggregated ecosystem metrics, and Polkassembly for proposal, referendum, vote, and discussion context.
- Endpoint and contract evidence: Before claiming an API is usable, check official endpoint families, auth headers, response shape, supported networks, rate-limit notes, and whether the source publishes docs an agent can inspect.
- PubFi route boundary: Treat Subscan gateway documentation as source-specific PubFi evidence. Treat DotLake and Polkassembly as Discovery source profiles unless a separate gateway readiness record supports live routing.
- Freshness and attribution: Governance answers can become stale, so agents should keep source timestamps, update cadence, attribution requirements, and public-source provenance visible in downstream summaries.
- Ranking and citation status: This topic resolves a query owner for Polkadot governance API demand, but Google ranking and AI answer citation remain pending until real readback records PubFi visibility.
- Agent-readable PubFi context: Link agents to /agents.md, /llms.txt, and /llms-full.txt for PubFi's public Discovery context, while keeping ranking and citation claims tied to GSC, public SERP, Vercel, and answer-engine readbacks.
Limits and boundaries:
- No universal PubFi governance gateway claim: Only source-specific evidence can support PubFi routeability. This page does not claim that every Polkadot governance source is callable through PubFi.
- Authentication varies by source: Subscan and DotLake require API-key planning, while Polkassembly public API use still needs network headers and rate-limit care for high-volume workflows.
- Governance context is not market data: Use market-data sources for price and token context; this topic is for proposal, referendum, vote, staking, treasury, and ecosystem-governance workflows.
- AI citation is not inferred: Answer-first structure and llms export readiness do not prove ChatGPT, Claude, Perplexity, Google, or Bing citation until the configured readback harness observes it.
FAQ:
- What API can I use for Polkadot governance data?: Start with the governance workflow. Subscan fits indexed explorer-style governance, account, staking, and extrinsic reads; DotLake fits official aggregated Polkadot ecosystem metrics; Polkassembly fits proposal, referendum, vote, and discussion context. PubFi Discovery compares these sources and keeps PubFi routeability source-specific.
- Is Subscan a good Polkadot governance API source?: Subscan is a strong starting point when the workflow needs indexed Substrate and Polkadot account, staking, extrinsic, and governance reads. PubFi has Subscan gateway documentation, but upstream API-key setup, supported network scope, and route limits still apply.
- When should I use DotLake API for governance data?: Use DotLake API when the product or agent needs official aggregated Polkadot, Kusama, and Substrate ecosystem metrics, including governance-related metrics. Its OpenAPI describes Bearer API-key authentication, so treat it as a server-side integration candidate rather than an anonymous browser call.
- When should I use Polkassembly for governance data?: Use Polkassembly when the workflow needs proposal, referendum, vote, delegation, comment, or discussion context around Polkadot governance. Its public API documentation includes network headers and rate-limit cautions, so high-volume agent workflows need implementation review.
- Does PubFi route every Polkadot governance API today?: No. PubFi Discovery can compare Polkadot governance sources and point to source-specific route evidence. Subscan has PubFi gateway documentation; DotLake API and Polkassembly are public source profiles unless a separate gateway readiness record says otherwise.