N2YO satellite tracking: Intelligence Source Guide

N2YO turns the public satellite catalogue into answers: where an object is right now, when it next passes over a given point, and what is overhead at a coordinate. It is the fastest route from a satellite name to observer-relative geometry, at the cost of not controlling the assumptions.

At a glance

Source	N2YO satellite tracking
Category	Aviation & Space › Satellite Tracking & Orbital Data
Homepage	https://www.n2yo.com/
Machine interface	https://api.n2yo.com/rest/v1/
Format	JSON
Access	Free registration — API key at no cost
Disciplines	Space Intelligence
Mission domains	Space & Satellite Intel

Real-time satellite positions. — as catalogued in the platform’s own source registry.

N2YO is a satellite tracking website with a small, well-documented REST API, run independently rather than by an agency or a company. It does not generate orbital data. It ingests the same publicly distributed general perturbations element sets that CelesTrak and Space-Track publish, runs an SGP4-class propagator server-side, and exposes the results as endpoints that answer observer-relative questions directly. The API is organised around a handful of operations: retrieve the current element set for a catalogue number; compute a series of positions over the next few seconds or minutes for a given observer location; predict visual passes, meaning passes where the satellite is sunlit and the observer is in darkness; predict radio passes, meaning passes above a minimum elevation regardless of illumination; and list objects currently above a given point within a search radius, optionally filtered to a category such as amateur radio satellites, weather satellites, navigation constellations or the brightest objects. Access requires a free API key obtained by registering on the site, passed as a query parameter. Responses are JSON and include an informational block naming the satellite and reporting a running transaction count, which is how the service communicates your usage back to you.

The analytical job here is the reduction from orbital mechanics to observer geometry, and its value is that it removes an entire class of implementation errors. Propagating an element set correctly is not hard in principle and is easy to get subtly wrong in practice – wrong propagator, wrong time system, wrong coordinate frame, wrong horizon assumption, wrong handling of the observer's altitude. N2YO has already made those decisions and applied them consistently, which means a small team without an astrodynamics specialist can ask and answer a real question in an afternoon: was anything overhead at this coordinate at this time, when is the next window, was the object illuminated. The visual-versus-radio pass distinction is the part that matters most and is most often overlooked elsewhere. A visual pass requires the satellite to be in sunlight while the ground observer is in darkness, which is a fundamentally different geometry from a radio pass that only requires line of sight. Confusing the two produces false conclusions in both directions – an analyst who assumes an object could be photographed when it was in Earth's shadow, or who assumes it could not be received because it was not visible. N2YO gives you both as separate products, correctly computed, which is genuinely useful even for teams who could compute them themselves.

Who publishes it, and why that matters

N2YO is an independently operated site of long standing, not an institution. It has been running for many years, its API has been stable across that period, and it serves a large community of amateur satellite observers and radio operators. That is a good track record, and it is also the whole of the assurance available: there is no service level agreement, no support contract, no published continuity plan, and no organisation behind it that would survive its operator losing interest. The funding model appears to be advertising on the website plus the operator's own effort, which means the free API tier is a courtesy rather than an entitlement. Two consequences follow. First, do not build anything operationally load-bearing on this API without a fallback path that computes the same geometry locally from CelesTrak element sets – the fallback is a day of work and the dependency is otherwise unbounded. Second, respect the transaction limits genuinely rather than nominally, because the cost of your traffic falls on one person. For casual and mid-volume analytical use it is an excellent tool; as a production dependency it is a single point of failure with no owner obliged to fix it.

Provenance is the first question to ask of any dataset and the one most often skipped. Who collects it, what their incentive is, whether they publish a methodology, and whether they correct the record when they get something wrong all bear directly on how much weight a finding drawn from it can carry.

What a record actually contains

The fields you will be working with, what each one means, and whether it is something you can pivot on. Read the meanings carefully — more analysis is wrecked by misreading a field than by failing to find one, and a field that looks like an observation is often an inference.

Field	Type	What it means	Pivot value
info.satid	int	The catalogue number of the object the response concerns. This is the identity anchor and the only field in the response that reliably ties the answer back to a specific object in the public catalogue.	CelesTrak and Space-Track records for the same object, launch metadata, international designator, orbital history.
info.satname	string	The catalogue's name for the object as N2YO holds it. Useful for display and worthless for matching, because names vary between distributors and change over a spacecraft's life.	None reliable; always pivot on the catalogue number instead.
info.transactionscount	int	Your running usage count against the applicable limit, returned in every response. This is the service telling you how close you are to being cut off, and it should be logged rather than discarded.	Your own collection health monitoring; not an attribute of the satellite.
satlatitude	int	Sub-satellite latitude in degrees at the requested instant – the point on the Earth directly beneath the object, not a position of anything on the ground.	Ground track construction, correlation with imagery footprints and RF observation locations.
satlongitude	int	Sub-satellite longitude in degrees. Combined with latitude this gives the nadir point; the actual sensor or antenna footprint extends well beyond it and is not modelled here.	Ground track, overflight windows for an area of interest, correlation with timestamped ground events.
sataltitude	int	Height above the Earth's surface in kilometres at the requested instant. Varies over an orbit for anything eccentric and is the fastest way to sanity-check that you are looking at the object you think you are.	Orbital regime classification, horizon range estimation, plausibility checks against the catalogue.
azimuth	int	Compass bearing from the specified observer position to the satellite, in degrees. Only meaningful in relation to the observer coordinates you supplied, so those coordinates must be recorded with the result.	Antenna pointing, line-of-sight terrain masking analysis, correlation with directional RF observations.
elevation	int	Angle above the observer's horizon, in degrees. Negative values mean below the horizon. This is the field that determines whether a pass is usable, and the threshold you consider usable depends entirely on terrain and equipment.	Access window determination, minimum elevation filtering, terrain obstruction assessment.
ra / dec	int	Right ascension and declination – the object's position on the celestial sphere as seen from the observer. Relevant for optical observation and for cross-referencing against star field imagery.	Optical observation planning, correlation with astronomical imagery and satellite streak identification.
timestamp	timestamp	Unix time in UTC for the computed position or pass event. Every temporal claim in this API is UTC, and the single most common integration bug in this domain is treating it as local time.	Timeline correlation with any other timestamped observation; convert once, at the edge, and record the offset.
startUTC / maxUTC / endUTC	timestamp	Pass window boundaries and the time of maximum elevation. The start and end are defined by the elevation threshold you requested, so the same pass has different boundaries under different thresholds.	Access window construction, correlation with imagery acquisition times or RF activity logs.
mag	int	Estimated visual magnitude at maximum elevation for a visual pass. It is a model estimate based on assumed reflectivity and geometry, not a measurement, and it is unreliable for objects with unusual shape or attitude.	Optical observability planning; treat as an ordering heuristic rather than a photometric value.
eclipsed	enum	Whether the satellite is in the Earth's shadow at the given moment. This is the field that separates a genuine visual observation opportunity from an object that is present but unlit, and it is routinely ignored.	Illumination-dependent analysis, discrimination between optical and radio access windows.
tle	string	The element set the service used, returned by the element set endpoint. Retrieve and store this whenever a result matters, because it is the only way to know what the answer was actually computed from.	Epoch age assessment, independent recomputation, reconciliation against CelesTrak or Space-Track.

Coverage — and what is not in it

Coverage is inherited, not original. The object population is whatever the public catalogue contains, which means tens of thousands of tracked objects with the same censoring – withheld sensitive payloads, unpublished uncorrelated tracks, and nothing below the tracking threshold. Geographic coverage is global in the sense that you can supply any observer coordinate on Earth and get a geometrically valid answer; there is no sensor network here whose footprint could limit you. Temporal coverage is the real constraint and it runs forwards, not backwards. The position endpoints answer questions about now and the immediate future, and pass prediction covers the coming days. There is no historical query surface: you cannot ask where an object was last March, and attempting to reconstruct it by feeding an old element set into a current query is not supported. Update rhythm follows the upstream catalogue, so element sets refresh a few times a day for well-tracked objects and less often for others. The category filters on the overhead endpoint cover the practical groupings an observer cares about – amateur radio, weather, navigation, brightest objects, space stations and similar – and are a curated convenience rather than an authoritative taxonomy.

Known blind spots

Absence of evidence here is not evidence of absence. These are the conditions under which N2YO satellite tracking will not show you something that is nevertheless real:

• There is no historical query capability. Every endpoint answers a question about now or the near future, so any investigation about a past event has to be done elsewhere, with archived element sets and your own propagator.
• The object population is inherited from the public catalogue and carries all of its censoring: sensitive payloads withheld, uncorrelated tracks unpublished, sub-threshold debris invisible. N2YO cannot show you what the catalogue does not publish.
• Terrain is not modelled. An elevation of five degrees is reported identically whether the observer is on an open plain or in a valley, so computed access windows overstate real access wherever the horizon is obstructed.
• Sensor and antenna characteristics are not modelled. The API tells you the satellite was above the horizon, not that a camera could resolve anything or that a link would close, and the gap between those is where most analytical errors live.
• Magnitude estimates assume a generic reflectivity and attitude, so tumbling objects, unusual geometries and large deployable structures produce brightness predictions that can be wrong by several magnitudes.
• Propagation error from the underlying element set passes straight through with no uncertainty reported. A precise pass start time computed from a four-day-old element set is precise and wrong, and nothing in the response indicates this.
• The service is a single independently operated site with no continuity commitment, so an outage or a change in terms removes the capability entirely and without notice.
• Transaction limits mean the API cannot support population-scale analysis. Anything that would require iterating over thousands of objects has to be done locally from bulk element sets rather than through this interface.

Write the blind spot into the product. A statement that something “was not observed in N2YO satellite tracking” is defensible; a statement that it “did not happen” is not, and the difference is what survives cross-examination.

Access, licensing and what you may do with it

Access model: Free registration — an account or API key, at no cost

Register on the website for a free API key, then pass it as a query parameter on every request. There is no OAuth flow, no token refresh and no per-request signing – the key is the whole authentication story, which means it must be kept out of client-side code and out of repositories, because anyone who obtains it consumes your quota and their traffic is attributed to you. The base path is versioned, and each operation takes the catalogue number and, where relevant, observer latitude, longitude and altitude in metres, plus a horizon threshold for pass predictions. Responses always include the informational block with the running transaction count, so instrument your client to log it and alert before you approach the limit rather than discovering it as a wall of errors. For anything beyond occasional lookups, cache aggressively: pass predictions for a fixed observer and a fixed satellite do not change meaningfully within a few hours, and re-requesting them every minute wastes a shared resource for no analytical gain.

Licence

The terms of use published on the site are the authoritative statement and should be read directly; they have been the practical constraint for years and they govern automated use. What can be said with confidence is that the underlying orbital data originates from the publicly distributed catalogue and carries whatever obligations that data's own distributors impose, and that N2YO's computed products – pass predictions, position series, magnitude estimates – are the site's output rather than public domain government data. Redistributing N2YO responses in bulk, reselling them, or building a commercial service whose core function is reserving this API is a different proposition from using it for internal analysis, and the former needs a direct conversation with the operator rather than an assumption. For research, journalism and internal investigative use, attribution and restraint are the operative norms.

Rate limits and fair use

The service enforces hourly transaction limits per endpoint category and reports your running count in every response, which is an unusually honest design and should be used as intended. The practical guidance is straightforward: this is not a bulk interface. Requesting a position series covers a span of seconds in a single call, so asking for a longer window costs one transaction rather than many – use that. Pass predictions for several days ahead cost one transaction, so request the full window once rather than re-querying daily. Cache element sets rather than re-fetching them, since they only change a few times a day. If your requirement is genuinely high volume – monitoring hundreds of objects, or computing access for many observer locations – do not attempt it here. Pull bulk element sets from CelesTrak and run SGP4 locally, which is unlimited, faster, reproducible and does not impose your workload on a volunteer-scale service.

Licensing changes, and it changes without warning. A dataset that was free for research this year may not be free for commercial or evidential use next year. Confirm the current terms before you build a dependency on it, and record the terms you relied on alongside the data — the licence in force at the time of collection is part of the provenance.

Collecting it

How N2YO satellite tracking is actually pulled, in the order you would set it up. Prefer the bulk or export interface over per-item lookups wherever one exists: it is kinder to the publisher, faster for you, and gives a reproducible snapshot rather than a series of point-in-time answers you cannot reconstruct later.

Method	Format	Cadence	Notes
Element set retrieval	JSON	a few times daily per object	Fetch and store the element set the service is using. This is the single most important call to make, because it is the only way to know the epoch behind every other answer.
Position series	JSON	on demand	Request a span of positions in one call rather than repeated single-instant queries. Supply the observer coordinates and store them alongside the result, because azimuth and elevation are meaningless without them.
Visual pass prediction	JSON	daily per observer-object pair	Passes where the object is sunlit and the observer is in darkness. The correct product for any question about optical observation, photography or naked-eye visibility.
Radio pass prediction	JSON	daily per observer-object pair	Passes above a specified elevation regardless of illumination. The correct product for communications and RF questions, and a different answer from the visual endpoint for the same object and observer.
Objects above a point	JSON	on demand	Enumerates what is currently overhead within a search radius of a coordinate, optionally by category. The fastest way to turn a timestamped ground event into a candidate list of overhead objects.
Local recomputation fallback	bulk	as needed	Mirror element sets from CelesTrak and run SGP4 locally for anything at volume or in the past. This is the escape hatch from every limitation above and should be built before you need it.

Ingesting it into the platform

Every step below is idempotent and cursor-based: interrupt one and it resumes from where it stopped rather than duplicating rows or losing progress. Collection is recorded per source, so a feed that quietly stops publishing shows up as a stale timestamp instead of silently thinning your coverage.

1. Register the source with its dependency recorded — Add N2YO in sources.php with an explicit note that its data derives from the public catalogue and that its outputs are computed rather than observed, so a later analyst does not treat a pass prediction as an observation.
2. Store the API key as a credential, not configuration — Keep it out of source control and out of anything client-facing. The key identifies your organisation to the operator and its traffic is attributed to you regardless of who actually made the calls.
3. Capture the element set with every result — During ingest.php, retrieve and store the element set alongside any computed geometry, and derive epoch age at ingest time. A stored pass prediction without its element set epoch cannot be quality-assessed later.
4. Record observer parameters as part of the record — Latitude, longitude, altitude and the elevation threshold used are not query metadata – they are part of the meaning of the answer. Store them in the record so the result is interpretable without the original request.
5. Separate visual and radio access as distinct record types — Do not collapse the two pass products into one access table. They answer different questions, have different geometry, and merging them produces findings that are wrong in whichever direction the analyst was not thinking about.
6. Correlate with timestamped observations — Use correlate.php to relate computed access windows to independent timestamped events – imagery acquisition, RF logs, reported sightings – and record every correlation as an inference with the propagation uncertainty attached.
7. Monitor the transaction counter — Log the returned transaction count on every call and configure an alert in alerts.php before the limit, so quota exhaustion appears as a managed collection event rather than as a silent gap in your data.
8. Build the local fallback path — Configure a parallel collection from CelesTrak into the same schema via pipeline.php, so that the analysis continues from locally propagated element sets if the API becomes unavailable or a question requires historical geometry.

Registered sources and their last-collected state are listed in sources.php, and the scheduled chain that keeps them current is in automation.php.

How it is wrong, and how to tell

Every dataset is wrong in characteristic ways. Knowing which ways is the difference between using a source and being used by one, and it is the part of source evaluation most often skipped because it is the part that takes work.

The computed geometry is sound and the service is well-regarded within the amateur satellite community, which is a demanding user base that would notice systematic errors in pass prediction quickly. Judge quality on two separate axes and do not conflate them. The propagation and coordinate work N2YO performs is reliable: positions, elevations and pass boundaries agree closely with independently computed results from the same element set, and the illumination modelling that distinguishes visual from radio passes is correctly implemented. The inherited data quality is the limiting factor, and it is entirely outside the service's control. Every answer is only as good as the element set epoch behind it, and the API does not report that age or any uncertainty in its computed outputs. Magnitude estimates are the weakest product and should be treated as a rough ordering rather than a prediction. The honest characterisation is that this is a correct calculator operating on data of variable freshness, presented without error bars. If you retrieve and inspect the element set alongside every meaningful result, you can supply the missing quality signal yourself; if you do not, you are consuming precise numbers of unknown validity.

Characteristic false positives

• A pass window computed from a stale element set is reported with the same apparent precision as one computed from a fresh set. The response contains no epoch age and no uncertainty, so the error is invisible unless you fetch the element set separately.
• Confusing visual and radio passes produces confident errors in both directions – concluding that an object could have been photographed while it was in Earth's shadow, or that it could not have been received because it was not visible.
• Computed access is treated as actual observation. The API says the geometry permitted something; it says nothing about whether a sensor was pointed there, a camera shutter opened, or a link was established.
• Observer altitude defaults or errors shift the horizon and change pass boundaries, so a coordinate entered without a sensible altitude produces windows that are systematically slightly wrong in a way nobody checks.
• Terrain blocking is invisible. Low-elevation pass segments reported as accessible are frequently blocked in reality, which inflates access windows in mountainous or urban environments precisely where the analysis usually matters.
• Matching an object by name rather than catalogue number picks up the wrong spacecraft, because names repeat across missions, differ between distributors and change during a spacecraft's life.
• Magnitude estimates are model output based on assumed reflectivity and attitude, and applying them to tumbling objects, large deployables or unusual geometries produces brightness claims that can be wrong by several magnitudes.
• Timestamps are UTC and are routinely rendered in local time somewhere in an analysis chain, which shifts every conclusion by the offset and is the most common integration defect in this entire domain.

None of these make the source unusable. They make it a source that requires corroboration before an assertion built on it goes into a product, which is true of every source and admitted by few.

Ageing

Nothing here is stored, so nothing goes stale in the usual sense – what ages is the answer you copied out of it. A pass prediction for tomorrow, computed today, is a forecast built on an element set that will be superseded several times before the pass occurs, and its boundaries will shift, typically by seconds to a few minutes for a well-tracked LEO object and considerably more for anything low, manoeuvring or poorly tracked. A prediction more than a few days out should be treated as an indication that a window exists, not as a schedule. Position queries age instantly and are only meaningful at the instant requested. The API key ages too, in the sense that terms and limits change without the key changing, so a client that worked last year may be operating outside current expectations. A stale record in your store looks like a pass window with a precise start time and no element set epoch beside it, and the remedy is structural: refuse to persist a computed geometry without the element set it came from and the time you retrieved it.

What this source feeds

A source is only worth what it lets you conclude. These are the disciplines that collect through it, the mission domains it serves and the data points it yields — every one is a tag, so you can follow any thread from here into the rest of the library.

Collected by these intelligence disciplines

• Space Intelligence

Serves these mission domains

• Space & Satellite Intel

Yields these data points

• Satellite Imagery
• GPS Coordinates

How each sector uses N2YO satellite tracking

The same dataset is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The records are shared — the constraints, thresholds and outputs are not.

🎖 Military and defence

Useful at the planning and awareness level rather than as an operational tool. For a fixed location it answers when an object is overhead, at what elevation, and whether it is illuminated, which supports concealment timing, sensor scheduling and the reciprocal question of what an adversary's overhead assets can compute about your own patterns. The constraints are important and disqualifying for some uses: no terrain masking, no sensor modelling, no historical query, no uncertainty, and an inherited catalogue that omits exactly the reconnaissance assets most relevant to force protection. Treat it as a fast orientation tool that tells you which questions are worth asking of better sources, and never as an authoritative overhead schedule.

🕵 National intelligence

The overhead-objects endpoint is the genuinely distinctive capability for SPACEINT work: given a timestamped event at a coordinate, it produces a candidate list of what was above that point, which is a fast first pass on questions about imagery provenance, satellite communications availability and RF correlation. The visual and radio pass distinction supports a real analytical discrimination between optical and communications geometry. The structural limitation is that the source is derivative and forward-looking – it cannot answer historical questions and it inherits every gap in the public catalogue – so it belongs in the triage layer of a workflow whose serious work is done against archived element sets with a local propagator and a stated error budget.

👮 Law enforcement

Investigations involving satellite communications equipment – in maritime smuggling, illegal fishing, and sanctions evasion where vessels use satellite terminals – benefit from a quick test of whether a given constellation was accessible from a claimed position at a claimed time. Similarly, cases where satellite imagery is offered as evidence can be sanity-checked against whether the platform had geometric access. Both are corroborative geometry, not proof of communication or of collection, and the lack of historical query means the serious version of either analysis has to be reconstructed from archived element sets. Nothing produced here should be presented as an evidential product without independent recomputation and a documented propagation uncertainty.

🔍 Private investigation and corporate security

Corporate and private investigators use this mainly for verification rather than collection. It provides a cheap, fast check on claims made about satellite capability – whether a company's spacecraft actually pass over the areas it says it covers, how frequently, and at what elevations – which is directly useful in due diligence on space-sector and remote-sensing ventures. It also settles the recurring question of whether a satellite image could have been acquired when claimed. The professional caution is that a computed access window is an opportunity, not an event, and a report that describes it as the latter will not survive scrutiny.

📰 Journalism and OSINT media

For reporting that touches satellites, this is the accessible tool that lets a journalist without astrodynamics training make a checkable statement: this object passed over this place at this time, at this elevation, illuminated or not. It is particularly useful for the recurring verification question of whether a bright object in a photograph or video could have been a specific satellite, where the combination of pass timing, elevation, direction and illumination state is often decisive. Report the result as a computed prediction, name the element set epoch, and be explicit that geometric access does not establish that any observation was made. The absence of an object from the underlying catalogue is a disclosure policy fact and should never be reported as an absence from orbit.

🌍 NGO, humanitarian and human rights

Organisations doing satellite-supported documentation – environmental monitoring, human rights verification, disaster response – use this to plan when imagery of a site could be acquired and to sanity-check the acquisition times of images they receive. It requires no budget, no specialist software and no institutional relationship, which matters enormously for small organisations. The realistic assessment is that it supports planning and plausibility checking rather than evidence: for documentation intended to withstand challenge, the geometry should be recomputed locally from an archived element set with the epoch and uncertainty stated, and this service used to find the question rather than to answer it.

🎓 University and research

For teaching, this is close to ideal – it makes orbital geometry tangible without requiring students to first implement a propagator, and the visual-versus-radio pass distinction teaches the illumination concept better than a lecture does. For research, it is unsuitable as a primary data source: there is no historical access, no reproducibility guarantee, no uncertainty reporting and a transaction limit that precludes population-scale work. The correct research pattern is to use archived element sets and a documented open-source propagator, and to cite this service only where it was actually used, for example in observational campaign planning. Studies of the amateur satellite observation community itself may treat the service and its user base as an object of study in their own right.

Playbook: working N2YO satellite tracking end to end

A repeatable sequence from first pull to finished product. Each phase states what you are trying to establish, not merely what to click — the objective is a defensible chain of reasoning, not a completed checklist.

Phase 1 — Decide whether the question is forward-looking

This API answers now and next. If your question concerns a past event, stop here and work from archived element sets with a local propagator instead. A great deal of wasted effort in this domain comes from trying to coax a historical answer out of a forward-only service by feeding it stale inputs.

Phase 2 — Resolve the object to a catalogue number first

Take the identity from the public catalogue rather than from a name search, and record it. Names collide across missions, differ between distributors and change over a spacecraft's life, and a pass prediction for the wrong object is indistinguishable from a correct one until it fails.

Phase 3 — Pin the observer precisely

Latitude, longitude and altitude in metres are part of the question, not incidental parameters. Altitude in particular moves the horizon and shifts pass boundaries. Record the observer parameters with the result so the answer remains interpretable when someone reads it a month later.

Phase 4 — Retrieve the element set before the geometry

Call the element set endpoint and store what comes back. This is the step that converts an unfalsifiable number into an assessable one, because it gives you the epoch and lets anyone recompute the same answer independently. Skipping it makes every later quality question unanswerable.

Phase 5 — Choose the pass product that matches the physics

Ask for visual passes if the question concerns seeing or photographing, and radio passes if it concerns communication or reception. These are different geometries with different answers, and the illumination state is the discriminator. Getting this wrong is the most consequential mistake available in this API.

Phase 6 — Set the elevation threshold deliberately

The threshold defines the pass boundaries, so the same pass reported at zero degrees and at ten degrees is two different windows. Pick a threshold that reflects the real equipment and the real horizon, and state it in the finding. A default threshold silently chosen by a client library is an undocumented assumption inside your conclusion.

Phase 7 — Apply a terrain and obstruction reality check

The API's horizon is a perfect sphere. Compare the computed low-elevation segments against the actual skyline at the observer location using terrain data or local knowledge, and trim the window accordingly. In mountainous or urban environments this routinely removes most of a nominal pass.

Phase 8 — Convert access into an uncertainty band

Take the element set epoch age and the orbital regime and turn the crisp start and end times into a window with margins. For a fresh element set on a well-tracked LEO object the margin is small; for a several-day-old set on a low-perigee object during elevated solar activity it can dominate the answer.

Phase 9 — Use the overhead endpoint for event triage

When you have a timestamped observation at a coordinate and no candidate object, list what was above that point within a plausible radius and filter by category. This produces a candidate set to test, not an identification, and the discipline is to carry all candidates forward rather than seizing on the first plausible one.

Phase 10 — Corroborate before concluding

Test the candidate against independent evidence: an amateur observation network record, a received transmission, an operator statement, an independently computed geometry from archived element sets. A single computed pass that fits the story is the weakest possible basis for an identification and is exactly how confident misidentifications happen.

Phase 11 — Instrument and respect the quota

Log the returned transaction count on every call, alert before the limit, and cache anything that does not change within hours. If the work has outgrown the quota, that is the signal to move to local propagation from bulk element sets rather than to open a second account.

Phase 12 — Record the whole computation, not the answer

The finding is the element set, its epoch, the observer parameters, the elevation threshold, the propagator, the retrieval time and the result. Anything less cannot be reproduced, and in this domain a result nobody can reproduce will be wrong in a way nobody can find.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

What to pair it with

No single source carries a finding. These are the datasets that corroborate, extend or contradict this one — and a source that contradicts is worth more than one that agrees, because it is the only thing that will tell you when you are wrong.

Source	Relationship	What it adds
CelesTrak	prerequisite	The upstream source of the element sets N2YO propagates, and the route to unlimited local computation when the API's limits or forward-only scope become binding.
Space-Track.org	extends	Historical element sets, full catalogue metadata and decay predictions – everything N2YO structurally cannot answer because it only looks forward.
Heavens-Above	corroborates	Independent implementation of the same observer-relative pass and visibility predictions, which is the cheapest available cross-check on a result that matters.
SatNOGS	corroborates	Actual received transmissions from ground stations, which converts a predicted radio pass into evidence that a spacecraft was transmitting during it.
Skyfield	supersedes	Local propagation and observer geometry with full control over epoch, coordinate frames and assumptions, and no transaction limit. The right tool once the work becomes serious.
Sunrise-Sunset API	extends	Ground illumination conditions at the observer, which combined with the satellite's eclipse state completes the picture of whether an optical observation was actually possible.
NOAA Space Weather Prediction Center	corroborates	Geomagnetic activity that drives atmospheric density and therefore the rate at which low-orbit element sets degrade, which is the main reason pass predictions drift.

Legal, ethical and operational constraints

Use is governed by the site's own terms rather than by any statutory regime, and those terms are the first thing to read before automating anything. The orbital data underneath is public information and computing geometry from it is unrestricted in virtually every jurisdiction. What can attract scrutiny is the product you build: detailed overhead schedules for foreign military space assets, combined with other collection, can engage export control and national security regimes in some jurisdictions even when every input was public. Separately, using overhead access analysis to support imagery collection over private property or over individuals engages ordinary privacy and proportionality tests – the public availability of the geometry does not make the resulting observation proportionate. Finally, the practical legal exposure most organisations actually encounter here is contractual rather than statutory: exceeding transaction limits, redistributing responses in bulk, or reselling a service that fronts this API are breaches of terms that will end your access and could end worse.

Operational security

Every request carries your API key, which is registered to a real identity, and identifies precisely which catalogue number you asked about, from which observer coordinates, at what time. That is a considerably more revealing query than an unauthenticated catalogue fetch, because it discloses not just the object of interest but the location you care about it from. A sequence of pass queries for one satellite over one coordinate is, to anyone with access to the logs, a complete statement of an intelligence requirement. If either the object or the location is sensitive, do not use this service – propagate locally from bulk element sets, where the only thing the network sees is a routine download of a whole group. Where the API is used, avoid observer coordinates that identify a real site of interest, prefer a nearby generic point when the difference does not matter, and never let query cadence spike in correlation with an operation.

Two rules that hold regardless of jurisdiction. Collection that is lawful is not automatically proportionate, and a dataset assembled for one purpose does not carry consent for another. Where the records concern identifiable people, the question is not only whether you may hold the data but whether holding it serves the purpose you are accountable for.

Is it earning its place?

Sources accumulate. Feeds get added during an incident and are never reviewed again, and a decade later the pipeline is carrying dead weight that nobody dares remove. These are the measures that show whether N2YO satellite tracking is contributing anything, and they are worth baselining now so the answer is available later.

• Share of stored computed geometries that have an element set and epoch recorded alongside them, which should be one hundred per cent and is the single best indicator of whether the workflow is disciplined.
• Median element set epoch age behind your pass predictions, tracked by orbital regime, as the practical measure of how much margin your access windows need.
• Transaction consumption against limit by endpoint, logged from the response counter, so quota pressure is a managed signal rather than an outage.
• Agreement rate between N2YO pass boundaries and independently computed boundaries from the same element set, sampled periodically, which validates that your interpretation of thresholds and observer parameters matches the service's.
• Proportion of computed access windows that were corroborated by an independent observation – a received transmission, a sighting, an imagery timestamp – as the honest measure of predictive value.
• Count of analyses that had to be redone locally because the question turned out to be historical, which measures how often the triage step is being skipped.
• Number of findings where the overhead-objects endpoint produced a candidate that survived corroboration, against the number of candidates it produced, as a measure of that endpoint's real signal rate.

Beware of volume. Indicator counts rise easily and say almost nothing. Unique contribution — findings this source produced that no other source in your stack would have — is the measure that matters, and it is usually far lower than anyone expects.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

• Always fetch the element set alongside the geometry. Without the epoch, a pass prediction is a number with no assessable quality, and the whole difference between an analyst and a user of a website is that the analyst knows what the answer was computed from.
• Visual and radio passes are not two views of one thing. Illumination changes the geometry, and the correct product depends entirely on whether the question is about seeing or about receiving. Decide before you query.
• Access is opportunity, never observation. The API establishes that a line of sight existed. Whether anything was pointed, tasked, transmitted or recorded is outside this data and needs a different source.
• Set the elevation threshold yourself and write it down. Pass boundaries are defined by the threshold, so a window quoted without one is not a window, and default thresholds buried in client libraries are undocumented assumptions in your conclusion.
• The spherical horizon is a lie of convenience. Compare low-elevation segments against real terrain before treating them as usable, because in most real observer locations the first and last minutes of a nominal pass do not exist.
• Catalogue numbers, never names. Name matching in this domain fails silently and produces a perfectly plausible answer about the wrong spacecraft.
• Treat magnitude as an ordering, not a measurement. It is model output with assumed reflectivity, and objects that tumble or carry large deployables violate the assumption badly.
• Know when to leave. The moment the work needs history, volume, uncertainty quantification or reproducibility, the answer is a local propagator and archived element sets. Continuing to work through the API past that point produces results you cannot defend.
• Log the transaction counter as telemetry. It is the service telling you your own consumption, and treating it as noise is how an analysis stops mid-investigation with no warning.

Questions analysts actually ask

Where does N2YO get its data?

From the publicly distributed satellite catalogue – the same general perturbations element sets served by CelesTrak and Space-Track. It adds propagation, observer geometry and illumination modelling on top. It is not an independent tracking network and it cannot see anything the public catalogue does not publish.

Can I query where a satellite was last month?

No. Every endpoint is forward-looking, covering the present and the coming days. Historical geometry has to be reconstructed from archived element sets with a local propagator, which is why Space-Track's history classes exist. Feeding an old element set into a current query is not a supported workaround.

What is the difference between a visual pass and a radio pass?

A visual pass requires the satellite to be in sunlight while the observer is in darkness, so it is about seeing. A radio pass only requires line of sight above your elevation threshold, so it is about receiving. The same object over the same observer produces different windows for each, and choosing the wrong one is the most consequential error available here.

Why do my pass times differ slightly from another tool's?

Usually a different element set epoch, a different elevation threshold, a different observer altitude, or a different definition of pass start. Reconcile those four before assuming either tool is wrong. If they still disagree materially, recompute independently from the element set both were nominally using.

Is the API free, and what are the limits?

The key is free after registration and there are hourly transaction limits per endpoint category. The service reports your running count in every response, which is the intended mechanism for staying within them. If your workload genuinely needs more than the limits allow, the answer is local propagation from bulk element sets rather than additional accounts.

Can I use this to prove a satellite saw something?

You can establish whether the geometry permitted it, which is a useful test and often a decisive negative one. You cannot establish that a collection occurred – tasking, pointing, cloud cover and operator decisions are outside this data entirely. Write it as an access opportunity with a stated uncertainty.

Does it model terrain?

No. The horizon is treated as a perfect sphere at the observer's altitude, so obstructions from mountains, buildings and trees are invisible. In practice this means low-elevation portions of computed passes frequently do not exist, and any operational use needs a horizon mask applied separately.

How reliable are the brightness predictions?

They are a useful ordering and a poor measurement. The model assumes a generic reflectivity and attitude, so objects that tumble, carry large solar arrays or have unusual geometry can be off by several magnitudes. Use them to decide which passes are worth attempting optically, not to make photometric claims.

Should I build a production system on this API?

Not without a local fallback. It is a single independently operated service with no continuity commitment and a courtesy free tier. Mirror element sets from CelesTrak and implement local propagation into the same schema, so the loss of the API degrades your capability rather than removing it.

Standards, formats and interoperability

What this source speaks natively, and what it has to be translated into before a partner can consume it. Work that arrives in a recognised format is easier to defend, easier to hand over and easier to automate against:

• SGP4 and SDP4 are the propagation models the service applies to catalogue mean elements; the same models must be used for any independent recomputation of its results.
• The two-line element set and the CCSDS Orbit Mean-Elements Message are the containers for the underlying data, and the element set endpoint returns the legacy form.
• Catalogue numbers and COSPAR international designators are the interoperable identifiers linking a response back to the catalogue and to launch registration records.
• Times are Unix epoch seconds in UTC throughout, which is the interchange convention this API and the rest of the space domain rely on.
• Observer geometry follows the standard topocentric azimuth and elevation convention, with elevation measured from the local horizontal plane rather than from a terrain-corrected horizon.
• Amateur satellite service frequency coordination underlies the radio pass use case, and the category filters reflect the practical groupings that community uses.
• The platform exports derived space entities and access events in STIX 2.1, MISP, CSV, JSON and JSONL, so a computed pass window travels into a case alongside any other timestamped observable.

References

Primary documentation and authoritative references for this source. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

1. N2YO — N2YO. The service itself, including the interactive tracker that makes the underlying geometry legible before you automate anything.
2. N2YO API documentation — N2YO. The authoritative statement of endpoints, parameters, response shapes and transaction limits. Read it rather than any secondhand summary, including this one.
3. CelesTrak — CelesTrak. The upstream element set source, and the route to unlimited local computation when this API's scope or limits become binding.
4. Space-Track.org — United States Space Force. Official catalogue distribution including the historical element sets that make past-tense geometry possible at all.
5. python-sgp4 — Brandon Rhodes. Reference-quality propagator implementation with official test vectors – the tool for verifying that your independent recomputation is correct.
6. Skyfield — Brandon Rhodes. Observer geometry, illumination and access window computation locally, with explicit control over every assumption this API makes for you.
7. Heavens-Above — Heavens-Above. An independent implementation of the same predictions, useful as a cross-check and as a second opinion on visibility and magnitude.
8. SatNOGS — Libre Space Foundation. Open ground station network whose observation records turn a predicted radio pass into evidence of an actual transmission.
9. AMSAT — Radio Amateur Satellite Corporation. The amateur satellite community's reference point for frequencies, operational status and pass working practice, which is the context this API's radio products were built for.
10. Consultative Committee for Space Data Systems — CCSDS. Standards for orbital data exchange, including the message formats that define what the returned element set actually means.

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this source: it registers the API as a derived source rather than an observation, stores the element set and epoch alongside every computed pass, keeps visual and radio access as separate record types, and maintains a local propagation fallback so the capability survives the service.. Browse the full source catalogue, or follow any tag above into the rest of the library.