Mezcal ExplorerMezcalDocs
QuickstartBuildAgentsReference
Open explorer
Documentation homeQuickstartConceptsMonitor 10 Wallets
BuildAPIAdvanced UtilitiesProtocol RoutesAPI Surface PolicySDKTypeScript SDK

Live reference

Interactive API referenceReference hub
AgentsAgent CLIMCP Quickstart
Reference Catalogs
Docs/API/Protocol Routes

Protocol Routes

Public bridge-analytics protocol extension routes that sit outside the core explorer API.

API referenceReferenceQuickstartTypeScript SDK

In this guide

Migration noteUse this lane forReferenceBoundariesRollout order
Loading documentation content…
PreviousAdvanced UtilitiesExternal helper routes that are published, supported, and narrower than the main public lane.NextAPI Surface PolicyWhich Mezcal routes are official public API, advanced utilities, protocol routes, or internal-only.

On this page

Migration noteUse this lane forReferenceBoundariesRollout order
Mezcal ExplorerMezcalDocumentation

One product surface across the explorer, HTTP API, CLI, SDK, and MCP transport. The docs should guide you into the right path instead of behaving like a separate app.

Open explorerAPI referenceBack to top

Protocol routes

These routes are public, but they are bridge-analytics-specific rather than part of the default explorer API.

Private protocol validation surfaces are intentionally not published here.

Migration note

Effective April 12, 2026, the published protocol extension contract is narrowed to bridge-analytics reads only. Integrations that used previously generated protocol validation snapshots should treat those routes as private, unsupported surfaces and migrate immediately to the core API reference or the published Advanced utilities when a supported replacement exists.

There is no public compatibility window for the private validation routes because they were not part of the supported external API contract. If a partner workflow still depends on one, coordinate a protocol-specific access path with the maintainers instead of relying on the public docs/OpenAPI artifact. See the design note for the rationale, scope, migration guidance, and validation plan.

Use this lane for

  • wrapper analytics: GET /api/v1/SN_MAIN/analytics/wrappers and GET /api/v1/SN_MAIN/analytics/wrappers/txs
  • netflow analytics: GET /api/v1/SN_MAIN/analytics/netflows and GET /api/v1/SN_MAIN/analytics/netflows/assets

Reference

  • Interactive protocol routes reference

Boundaries

  • Start with the core API reference for status, blocks, txs, addresses, tokens, contract reads, and search.
  • Use Advanced utilities for published batch helpers such as tx/previews and address/summaries.
  • Do not treat infra probes, app bootstrap helpers, private protocol validation routes, or private mutation routes as public contract.

Rollout order

  1. Validate standard status, address, and token reads first.
  2. Move into protocol routes only when the integration is explicitly protocol-aware.