Summary

  • PeeringDB’s 18 September API v3 draft would distribute a public, read-only query surface while leaving writes on v2 at launch.
  • Cacheable access is a technical property, not a general reuse permission: the current acceptable-use policy still governs copying, bulk transfer and commercial applications.

A network engineer can query a public API without asking for a data feed. A software vendor deciding whether it may retain and resell what the API returns faces a different question. PeeringDB’s proposed API v3 brings that distinction into sharper view.

The 18 September document is still a first-call-for-comments draft. It proposes a public, read-only service designed to run from multiple locations alongside the current API, which the draft calls v2. The split is deliberate: most traffic is queries, so read servers could be distributed and cached, while updates continue through v2. The draft also proposes flat records, incremental synchronization and daily snapshots for bulk loading and fallback.

Those are useful engineering choices. The proposed service targets 99.95% availability, visibility of 99% of changes within one minute, and a 15-minute freshness ceiling for latest-data responses. That ceiling is an alerting target, not a cutoff: missing it should raise an alert but must not stop the service from returning data. Snapshots, third-party mirrors and a client’s own polling interval sit outside the freshness measure. The proposal also says every caller must see the same public dataset; API keys would not change data visibility.

None of those statements is a data-use licence. PeeringDB’s current acceptable-use policy says data may not be reproduced, stored in a retrieval system or transmitted without prior permission, except for approved Internet operational purposes. It treats troubleshooting, abuse reporting and Internet research and analysis as operational purposes, but says bulk handoff requires approval and excludes marketing lists, demographic mapping and other commercial applications. The policy also says each request is evaluated on its stated purpose.

That distinction matters because v3 is designed to make reading and caching easier, and its delta-sync design expects a client polling every five minutes to maintain a fresh local copy. The draft does not announce a change to the acceptable-use policy. A cacheable response, a daily snapshot and permission to build a commercial product from stored data are separate propositions. The document’s exclusion of third-party mirrors from its freshness and emergency-removal scope describes what PeeringDB measures and controls; it is not itself permission to mirror or redistribute.

The withdrawal language makes the boundary practical. The proposed public projection retains public contacts, notes and precise coordinates. PeeringDB would have to publish a retention window and provide emergency removal for data it serves, while third-party copies already held remain outside that policy. Deltas must expose deletions and withdrawals, but the draft has not yet published the OpenAPI details that would define exact requests, responses and compatibility behavior.

PeeringDB’s 21 September explainer says the current API would initially remain for updates and asks users for input on a possible transition if the organization later chooses to retire it. Access and rate-limit policies are still to be decided before implementation; the exact v3 path and several field and object-type decisions also remain open. The Product Committee is asked to decide field and object changes separately with community input; an issue request does not commit a field change to the release.

The proposal is therefore more than a latency project, but less than a settled distribution regime. Operators can assess the intended read/write split and freshness targets. Software builders still need a clear account of which local copies are permitted for operational work, when separate permission is required for bulk transfer or commercial use, and how withdrawal signals should be handled. The next draft should make those boundaries as legible as its response contract.

Sources