Query network, exchange, and facility data via the PeeringDB API
domain: peeringdb.com · 5 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Use anonymous GET requests for public read access, or create an API key (user-level or organization-level) at peeringdb.com and send it as Authorization: Api-Key <key> for write operations or higher rate limits.
Query a network by ASN with GET https://www.peeringdb.com/api/net?asn=<ASN>, or fetch a single object directly with GET /api/net/<id>.
Use field filter modifiers for other object types (org, fac, ix, poc, and derived types like ixlan, netixlan, netfac) — numeric fields support __lt/__lte/__gt/__gte/__in, string fields support __contains/__startswith/__in.
Pass depth=0-4 on requests to expand nested _set relations, remembering the multi-object list endpoint only expands _set fields, not single foreign-key relations (unlike single-object GET).
Parse every response inside the {meta: {...}, data: [...]} envelope, since data is always an array even for single-object lookups.
Known gotchas
The multi-object GET's depth parameter only expands _set relations, not single foreign keys — an easy source of missing nested data compared to single-object GET behavior.
PeeringDB's Acceptable Use Policy explicitly prohibits commercial use and unsolicited communications derived from the data — factor that into any integration built on this data.
API keys are shown in full only once at creation — store them immediately or you'll need to regenerate.
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?