SQD developer resources

SQD Portal API

The SQD Portal is a plain HTTP API serving onchain data from 130+ networks, with no node, archive, or indexer of your own. Responses to the stream endpoints are JSON Lines, so a client reads them incrementally instead of buffering a whole range. Start at GET /datasets: the dataset name every other call takes comes from that list.

OpenAPI specification

The whole documented Portal surface is described in OpenAPI 3.1 at sqd.dev/openapi.json. Every operation carries a stable operationId, typed parameters, and a response schema, which is what a function-calling adapter or a client generator needs. It is also the document to diff in a pipeline when you want to detect a change to the API.

Authentication

The public Portal at https://portal.sqd.dev is shared capacity, intended for development and bounded evaluation. Authenticated and dedicated portals take an API key in the x-api-key request header. Paths and payloads are identical either way, so a client written against the public Portal moves to a dedicated one by adding one header and changing the host.

Rate limits and retries

When the Portal is at capacity it answers with error type rate_limit_error and code overloaded. A Retry-After header is mandatory on those responses, is always at least one second, and is always a count of seconds rather than an HTTP date. Honor it: that value is the throttle signal, and there is no separate quota header to poll.

A transient failure arrives as availability_error instead, which may also carry Retry-After and is safe to retry with your own backoff when it does not. Branch on error.type, match on error.code, and never parse error.message.

Browser clients can read the throttle signal: the Portal exposes retry-after and x-request-id through CORS, alongside the stream metadata headers x-sqd-data-source, x-sqd-head-number, x-sqd-finalized-head-number and x-sqd-finalized-head-hash. None of those are on the Fetch safelist, so without that exposure a browser would see a status code and nothing else. Quote x-request-id when reporting a problem.

Versioning and deprecation policy

The Portal API carries no version in its URL and no version header. There is no /v1/. Every client talks to the same surface at https://portal.sqd.dev, and that works because the surface grows by addition: new dataset types, new block and transaction fields, and new datasets appear without changing what an existing request means.

The surface that does move is the dataset catalogue. Datasets are added as networks are onboarded, and occasionally retired. A retirement is announced in advance on the Announcements page and in the developer chat, naming the affected datasets and a date, so watch that page rather than polling for removals. After the date, GET /datasets/{dataset}/metadata answers 404 with error.code of unknown_dataset.

The SDKs are versioned separately, as npm packages following semantic versioning. A breaking change lands in a major release with a migration guide, and the Portal keeps serving older SDK versions: the wire format they depend on is the same additive surface described above.

MCP servers

Two SQD MCP servers, for two different jobs. The SQD Portal MCP server at https://portal.sqd.dev/mcp exposes onchain queries as agent tools, across EVM, Solana, Bitcoin, Substrate and Hyperliquid. The SQD Documentation MCP server at https://docs.sqd.dev/mcp answers questions from the documentation. Both speak the Streamable HTTP transport and negotiate protocol version 2025-06-18. Neither needs a key.

One handshake detail decides whether a client connects at all. The Streamable HTTP transport requires the initializing POST to accept both media types, and a request sending only application/json is answered 406 Not Acceptable, as is a request with no Accept header. The exact call that works:

Most MCP clients send that header pair for you. Add the server by URL and the client handles the rest; the setup guides cover Claude, Cursor, VS Code and the rest.

Squid CLI

The Squid CLI is published on npm as @subsquid/cli and installs one command, sqd. It scaffolds an indexer from a template, runs it locally, and deploys and manages it on SQD Cloud, which means an agent or a script can drive the whole lifecycle without writing an API client first.

SDKs

Two SDKs and the raw API, for three different jobs. The Pipes SDK builds streaming pipelines into ClickHouse, PostgreSQL, BigQuery or Parquet. The Squid SDK builds indexers that serve a generated GraphQL API over PostgreSQL. Calling the Portal API directly needs no dependency at all and works from any language.

Files for agents

The machine-readable surfaces sqd.dev publishes, each at its standard location. The API catalog is RFC 9727, the MCP server card follows the SEP-1649 draft, and the skill index follows the Agent Skills discovery RFC. The homepage advertises all of them in a Link response header, so a client that reads headers finds them without a second request.

Any page on sqd.dev is also served as Markdown to a request that asks for it. There is no .md suffix to append: negotiation is on the Accept header alone.

Support

Technical questions go to the developer chat, where the engineers who maintain the Portal and the SDKs answer. Dedicated portals, volume, and pricing go through the contact form.