Summary

  • PeeringDB’s API v3 draft proposes a public, read-only service designed for multiple locations, with targets for availability and data freshness.
  • The draft is a request for comment, not a release: access rules and the exact API contract are still unfinished, and no live performance is shown.

The draft gives a future API a clock before it gives operators a launch date. PeeringDB’s document, dated 18 September, sets a target of at least 99.95% availability, says 99% of changes should appear within one minute, and sets a 15-minute ceiling for latest-data responses, including cached responses. It does not say when the service will be implemented. The status line calls it a first draft for comments and review.

APNIC’s 7 October PeeringDB update explains why the design is being discussed. Product Manager Leo Vegoda identifies two aims: separate reading from writing so copies can be served in multiple places, and make common relationship queries more efficient. He asks API users to comment before implementation. The detailed contract is on PeeringDB’s own draft page; APNIC is the publication channel, not the API operator.

The proposal keeps the boundary narrow. Version 3 would be public and read-only, alongside version 2; writes remain on v2. Its first search scope is name and ASN lookup. It leaves out private or per-key views, nested depth expansion, ranked full-text search, and spatial or distance queries. Flat object responses, incremental synchronization, and daily snapshots are meant to let users build and refresh their own copies. Responses would identify a dataset version, while a version endpoint would report how fresh the source data is.

The freshness figures have defined edges. They measure from a change at the source to a latest-data response and include cache delay. Daily snapshots, historical traversals, third-party mirrors, and a client’s own polling interval are excluded. The 15-minute ceiling is an alerting target, not a cutoff: the draft says a miss should raise an alert, not stop the service from serving data.

That distinction matters to operators who use PeeringDB to inspect networks, facilities, and exchange relationships. The draft offers a way to specify how quickly its public view should catch up; it does not establish that the view is complete or that participant-maintained records are correct. Nor is PeeringDB a routing control plane: the proposal changes neither RIR allocations nor BGP decisions.

Before implementation, the draft leaves important parts open. OpenAPI is to settle query syntax, responses, errors, and compatibility. The access and rate-limit policy is also still to be decided. The document gives no measurement window for its availability target and no release date. A number in a design is not an uptime record.

The next useful evidence will be a revised specification, the chosen access rules, and eventually production measurements that distinguish source freshness from cache and client behavior. Until then, API v3 is a proposed contract for a future read path, not a service operators can depend on today.

Sources