Six commercial ground networks advertise an API for booking contacts. Read first-party on 17 October 2026, exactly one of them publishes an endpoint list, an authentication model and a sandbox you can read before you sign anything. The other five publish a sentence.

That is the whole finding, and it is cheap for anyone to check, which is the point. What follows is what each one says in its own words, what the difference costs a team building a scheduler, and why the obvious fix is not as available as it looks: the only standards body that has specified any of this stopped one layer short on purpose.

What the six actually publish

Skynopy's own site, read on 17 October 2026, offers "Access to ground networks with single API" and gives the network as 18 ground sites in operation. There is no documentation link on the page. ATLAS, on its Freedom product page the same day, offers "Single API Access to Global Federated Network", with no documentation link either.

Leaf Space goes further in prose and no further in substance. Its Leaf Line page, read on 17 October 2026, says it will guide you "through our user-friendly LEAF SPACE RESTful API, providing a sandbox environment and comprehensive documentation for seamless integration". The sandbox and the documentation are both real claims and neither is reachable from the public site; the homepage advertises "+40 ground stations" and no endpoint reference.

Sfera Technologies, on its ground stations page, invites you to "Integrate your mission control setup or digital command center with our REST API", and lists 12 active sites and 7 planned ones across VHF, UHF, S and X band. Groundcom, on its shared network page, says that "Whether you use our intuitive web GUI or our compatible REST API, integration is effortless" and adds that it supports TCP, UDP and MQTT. Neither page links an endpoint reference, an authentication model or a schema.

I probed the obvious documentation hosts as well, since a missing link is not the same as a missing site. Measured today: docs.skynopy.com and docs.sfera.earth do not resolve at all, and docs.groundcom.space resolves but fails its TLS handshake. Those are this reader's results from one network path on one day, not a claim about anybody's infrastructure.

Then there is SSC Space Go, which is the reason this piece is a comparison rather than a complaint. Its documentation index served to an unauthenticated reader today and links an External ICD, an External API reference, a sandbox ICD, antenna and modem specifications, terms and conditions, and a Swagger UI. The API reference gives a base path of /api/v1 and, counted off the page today, fourteen operations across eleven paths. Authentication is documented as HTTP bearer with a JWT, or OAuth 2.0 using the authorisation code flow.

For scale outside the independent GSaaS set: AWS Ground Station's public API reference listed 40 actions today, ReserveContact and ListContacts among them, readable by anyone with a browser and no account.

What the difference costs

An endpoint list is not the valuable part. The valuable part is the shape of the interaction, because that is what your own code has to be built around.

SSC's external ICD describes the booking sequence plainly: compute visibility from a TLE, upload the TLE, call GET /contacts/availability, submit a POST /contacts with site, spacecraft, start, end and service type, receive a contact identifier, then poll GET /contacts/{contact_id} while the state moves from NEW to PENDING to CONFIRMED or REJECTED. The ICD states the consequence in one line: "It is the customer's responsibility to poll and check for the latest state."

That single sentence is a design input. A booking that is asynchronous and pollable means your scheduler needs a pending state, a reconciliation loop and a policy for a rejection that arrives after you have already told an operator the pass is theirs. A booking that is synchronous needs none of that. Knowing which one you are buying before you sign is worth more than the endpoint names. The same goes for the authentication model: an unattended scheduler that needs an interactive authorisation code flow is a different piece of software from one holding a long-lived token.

Against the other five, none of that is knowable in advance. You can book a sales call, agree commercial terms, and only then discover the interaction shape your scheduler has to absorb. BeamDesk's own live adapter for commercial ground segment is written against exactly that constraint: the base URL for the undocumented networks is configuration rather than a constant, the path is a documented default rather than a verified one, and whatever the network returns is reported verbatim, including a 404, because a 404 is the honest answer when the path is wrong for your account. BeamDesk has no contract with any network named in this piece, and nothing here should be read as a commercial relationship with any of them. The adapter is written to be configured by whoever does hold the contract.

The honest limit on the other side: SSC publishes the path, not the host. The production base URL still arrives with the credential, and the reference documents which endpoints exist rather than every field in every record. Reading the docs first is not the same as writing the client blind. It is still the difference between a week of integration and a quarter of it.

CCSDS standardised the schedule and stopped one layer short

The obvious response is that this is a solved problem and the market should go and adopt the standard. Half of that is true.

CCSDS 902.1-B-1, the Simple Schedule Format Specification, is a Blue Book dated May 2018, and the current issue carries Technical Corrigendum 1 dated December 2021. Both dates are on the cover page, read first-party today. Its stated purpose is a standard format for "transferring scheduling information related to apertures at ground stations and/or relay satellites between space agencies and commercial or governmental spacecraft operators". Commercial operators are named in the purpose. This is not an agency-only document by its own account.

Section 1.2 is where it stops. The Recommended Standard is applicable to the schedule format and content "but not to its transmission", and where a schedule moves outside the scope of service management, the mechanism "should be specified in an ICD agreed by the parties involved". The body that specified the artefact declined, deliberately and in writing, to specify the interface that carries it.

The shelf behind it is not empty. The standard's own Figure 1-1 maps a family running from the 902.0-G concept green book through planning information, service agreements, service package data, service accounting, utilisation request formats, management services, best practices and common data entities, out to 902.13-M. I read one of those first-party as a cross-check: CCSDS 902.12-M-1, Common Data Entities, a Magenta Book dated February 2021. The XML schemas are registered and public at SANA, including the Simple Schedule schema under 902.1-B-1 and the 902.12 and 902.13 entity schemas.

What I could not establish is whether any of that family defines a binding to the thing every commercial network actually ships, which is an HTTP API with a token. CCSDS 902.10-B-1, Management Services, is named in Figure 1-1, and four attempts at its document URL returned 404 to this fetcher while the CCSDS publication tables did not render at all. Secondary accounts describe a SOAP binding for the service management exchanges. I have not read it, so this piece asserts nothing about it, and the gap is stated rather than filled.

Two corrections to BeamDesk's own register fall out of this, and they are the kind a person here has to apply by hand. The register pins 902.1-B-1 as "Blue Book, Sep 2018" where the cover says May 2018. And the pinned URL at public.ccsds.org/Pubs/902x1b1.pdf now redirects to ccsds.org and 404s there; the live file today is 902x1b1c1.pdf, the corrigendum-inclusive issue.

The case for the five

Publishing nothing is a defensible commercial position and it is worth stating properly rather than dismissing.

A GSaaS API is account-shaped. Which spacecraft, which service types, which sites and which bands you may book are all entitlements, so a generic public reference describes a thing nobody can call, and it costs real effort to write and keep current for no revenue until the first customer. Some operators also treat the endpoint list as attack surface. That argument is weak on its merits, since obscurity is not an access control, but it is honestly held and it is the one usually made in the room.

The strongest version of the defence is the one this article has just demonstrated. There is no published REST binding sitting there waiting to be adopted. Each of these teams would be writing an interface specification from first principles, in a market of fewer than a hundred plausible customers, while competing on antenna minutes rather than on developer experience.

Against that, two counterexamples in the same market, both verified today. SSC Space Go publishes its reference and its auth model while still gating the production host behind an account. AWS Ground Station publishes 40 actions and gates every one of them behind credentials. Documentation and access control are separable, and two networks have already separated them.

What would change my mind

A documentation host appearing. If docs.skynopy.com, docs.sfera.earth or docs.groundcom.space starts serving an endpoint reference, this survey is stale and the pattern is a website problem rather than a market one. That is a one-command check and I will make it again.

Leaf Space's claim is the specific one I would most like to be wrong about. It advertises a sandbox and comprehensive documentation. If that material is readable on sign-up rather than after contract signature, then for Leaf the gate sits at account creation rather than at procurement, and most of the cost described above does not apply to them.

If CCSDS 902.10-B-1, or anything else in the 902 family, does define a usable binding for a commercial booking interface, the standards half of this piece is wrong in an interesting way. The story would then be that a binding exists and the market declined it, which is a different and more damning article about the standard rather than about the vendors.

And if someone can show that operators overwhelmingly book through the web GUI and never call the API at all, then the published-reference gap is a niche developer grievance rather than an adoption cost, and the five are right to spend the effort elsewhere.

Sources