Summary

  • PeeringDB’s Copy API Query feature carries an Advanced Search selection into curl or a common scripting language, cutting the manual translation between a browser workflow and a repeatable query.
  • Its optional city map and table help locate facility records. Neither a plotted facility nor a copied query proves a live port, selected route, available service or commercial agreement.

Analysis

The useful handoff happens after the search

An interconnection shortlist often begins with a practical question: which networks, exchanges or facilities meet a particular set of conditions? The analyst enters those conditions into a web form, inspects the result and then faces a second task—rebuilding the same selection in a command line or an internal tool. That translation is small enough to seem trivial and large enough to be repeated, mistyped or left undocumented.

PeeringDB’s September product update says Advanced Search now includes Copy API Query. A user can run a search on the site, then take the resulting query to curl or use a format for a popular scripting language. The value is not that the database has suddenly become more authoritative. It is that the boundary between a human-selected filter and a machine-run request is easier to cross. A team can preserve the query expression in a runbook, inspect its parameters and decide whether it belongs in a recurring workflow.

This is a modest change with a practical economic effect. It lowers the cost of moving from exploration to a repeatable shortlist. A network engineer can test a location or presence filter in the interface before asking a script to process it. An analyst can hand colleagues the query conditions rather than a screenshot whose selections are hard to reconstruct. PeeringDB’s Search HOWTO already describes Advanced Search filters for location, network presence, service level and other features, along with JSON and CSV exports. Some features, including radius search, require an account.

Copying the query makes the transition visible; it does not remove the need to understand the request or its access requirements.

A map answers a spatial question, not a connectivity question

The same September update describes an optional in-page map on relevant Advanced Search pages. A profile control enables it; the map shows the distribution of facilities across a city while the table remains available. PeeringDB also maintains a separate KMZ download for viewing facilities in GIS tools, where additional layers can be shown or hidden.

Those views help with a real first-pass problem: a list of facility names is difficult to interpret as a city. A map can reveal clustering, distance and the difference between several records concentrated in one area and records spread across a metro. The table preserves the facility entries that sit behind the symbols. Together, they improve geographic discovery.

They do not show a network’s traffic, a route, a live cross-connect or a service contract. A facility marker says that a facility record appears in the selected result. It does not establish that a particular network has a lit port there, that the parties have agreed to exchange traffic, that a route is selected, or that capacity is available today. A map can make a shortlist easier to act on; it cannot turn a directory relationship into an operating relationship.

A query is repeatable; its result is not a snapshot

Copy API Query carries a search expression into a request. That is useful for repeating the filter logic, but it should not be mistaken for a preserved set of matching records. The feature description promises a query handoff, not an immutable result archive or a versioned record snapshot. This distinction matters whenever a result is used in a design review, procurement file or later incident reconstruction. To make the analysis auditable, a team should record when it ran the query, what parameters it used, what response it retained and which records it checked with their owners.

PeeringDB describes itself as a community-driven, user-maintained database and presents it as a starting point for interconnection decisions. Its data-ownership policy places responsibility on users to keep organization data current and describes how disputed records are handled. Volunteer validation and user stewardship are part of that model; neither should be misrepresented as a guarantee that every entry is current for a particular deployment.

The operational conclusion follows from the source’s own design: search helps find candidates, while the network, exchange, facility and counterparties remain the places to verify present conditions.

This is also separate from PeeringDB’s API v3 discussion. The September update describes that document as seeking feedback before design refinement and implementation, with proposed changes to read and write architecture and query efficiency. Copy API Query is an Advanced Search feature the same update says has already been delivered. One is an implemented interface handoff; the other is a proposal. Treating the query button as evidence that API v3 has shipped would collapse two different stages of change.

The operational payoff is disciplined discovery

The new workflow is most useful when a team keeps the stages distinct. Use Advanced Search to define a candidate set. Copy the query so the selection logic can be examined and reused. Use the map to understand where facility records sit within a city. Then verify the details that affect a commitment: current facility information, the relevant network’s own stated presence, a direct confirmation of port and cross-connect status, and the commercial terms that govern service.

That division of labour protects both sides of the process. Better search reduces avoidable analyst effort and makes a query easier to share. Explicit verification prevents a convenient interface from being treated as a certificate of operational readiness. A directory record describes an asserted state; it does not cause the network to connect. PeeringDB has made the route from discovery to automation shorter. The decision still belongs to the operator who must stand behind the resulting connection.

Sources