Who is this ASN or prefix? Registry, RPKI, IRR and PeeringDB in one call.

The right first step in almost any investigation. Give either asn or prefix. include may list rdap, rpki, irr, peeringdb (whois is not yet available through the API).

What does this ASN announce, and does it stick?

Returns each prefix with a server-computed persistence classification (persistent | intermittent | transient). Do not infer persistence from first_seen — use this.

Counts over time for target (asn:13335 or prefix:1.1.1.0/24). Replaces bulk event downloads. group_by=origin at daily granularity is the handover chart. Hour granularity and peer/event_type grouping are not available (the underlying rollup is daily).

Day-by-day origins for a prefix — THE persistence check. Returns each day's origin set, MOAS days, and classified transitions (handover vs episode vs intermittent). This is the direct fix for mistaking a transient blip for a migration.

How many observing peers had no route, and when. Returns an event-driven series plus server-computed outage windows (>=5% of peers routeless). Accepts multiple prefixes so a multi-prefix event resolves in one call. Keep the window tight — this reads raw events.

Platform findings for an ASN or prefix, with direction made explicit. direction (queried_entity_is_invalid_party | queried_entity_is_baseline | third_party) tells you whether the queried entity is the offender or the victim — reading actor_as against baseline_asns by hand inverts conclusions.

Transit structure for a prefix with prepending resolved: immediate upstreams and their share, plus top paths with collapsed_path / prepend_count.

An ASN's transit hierarchy over a window: upstreams (its providers) and downstreams (its customers), plus observed neighbours whose relationship is unknown.

Relationships are inferred provider->customer, Tier-1-anchored (~94% agreement with CAIDA). Peering is NOT inferred: other_connections are adjacencies we observed but cannot classify — do not present them as confirmed peers. Results reflect the requested date window; relationships change over time.

This is the transit TOPOLOGY (who provides transit to whom). For observed USAGE — which of those upstreams actually carry the network's routes and how lopsided that is — use path_diversity; the two are complementary.

How an origin's announcements FAN OUT through its upstreams toward our collectors — the observed propagation / path-diversity tree, weighted by how many vantage points take each branch.

Built ONLY from real observed AS paths (no inference), so it answers with high confidence: which upstreams actually carry this network's routes, and how lopsided that is. Each level-1 branch's share is the fraction of vantage points (of the total_vantage_points that see the origin) that reach it via that upstream, counted as DISTINCT collector+peer feeds. Shares are per-upstream coverage, not a partition — a network reached through several upstreams will have several high shares, so they can sum past 1.0. One dominant upstream with the rest low = effectively single-threaded; several high shares = redundant transit. is_tier1 marks where a branch reaches the Tier-1 core.

Pass prefix (a CIDR the ASN originates) to scope the tree to ONE prefix — useful for a MOAS prefix or to check a specific route's redundancy; the % then reflects just that prefix's paths.

NOT a traceroute: this is the control-plane spread of routes across upstreams as seen from route collectors, not the data-plane path a packet takes (peering and IXP handoffs are invisible to collectors). diverse=false means the origin is single-threaded or too thinly observed for a meaningful diversity view — read reason. Default window is 14 days (current routing); widen it for more history.

Translate raw BGP community strings (e.g. "3356:2065", "1299:2731") into their meaning, from a dictionary harvested from operators' own IRR objects, NLNOG, and the IANA/RFC well-knowns.

Each result carries: known (false = no published definition — don't guess a meaning), category (informational | action), subtype (geo | prepend | localpref | blackhole | no-export | relationship | …), description, optional geo, and the OWNER AS (the left side) with its resolved name — which is useful even when the community itself is unknown ("it's AS3356/Lumen's community"). inferred=true marks a meaning taken from a near-universal CONVENTION (e.g. any :666/:9999 = blackhole) rather than something the owner published — present those as conventional, not authoritative. matched_by shows the wildcard pattern that matched, when it wasn't an exact literal.

Baseline (window_a) vs event (window_b) for a target. Each window is {from, to}. dimension=volume compares totals; origin/collector compares the per-group breakdown so a new origin or a shifted collector mix is obvious. (upstream/paths comparison is not available via the rollup — use paths.)

Facility/IX intersection across an entity's upstreams — routing-only geolocation. Finds cities common to all upstreams' PeeringDB presence, which is far more reliable than GeoIP for leased/anycast space. Give a prefix (or an ASN, whose top prefix is used to derive upstreams).

Announced more-specifics inside a block, plus an estimate of unrouted space — allocated addresses never seen in the table, the easiest kind to announce unnoticed.

Bounded raw events for a NARROW window — last resort. Capped at 500 events; rejects windows over ~24h. Use only after timeline/reachability/origin_history have localised what you need to see at the message level.

Is today unusual, platform-wide? Aggregates recent anomalous detections so you can tell an ordinary busy day from a real event. Call this BEFORE describing anything as anomalous — an apparent spike is often just the platform's normal volume.

Full hygiene + exposure audit for an ASN you control — the single most valuable operator call. Checks RPKI/IRR coverage, MOAS, ROA max-length exposure, transit diversity and visibility, each with remediation. Sampling bounds the per-prefix checks to keep it fast.

Pre-flight: will announcing prefix from origin_asn validate? Checks the covering ROA (and max-length), IRR route objects, who announces it today, and — because freshly transferred space keeps the old holder's ROAs — whether the registration changed recently. Returns verdict clear | warn | blocked.

Where can the internet see this prefix, and where can it not? Peer and collector reach, upstreams, and — the useful part — a ratio against sibling prefixes. Absolute peer counts mean little; a prefix seen by 40 peers when its siblings are seen by 330 is being filtered.