The S-System SDK is available today for Python and Node/TypeScript. It covers flight operations and airport operations: live status, on-time performance, route analytics, stand utilization, and terminal congestion, from the platform that forecasts disruption up to four days out.
Nothing about the forecast changes today. What changes is how far it can travel inside your airline.
A forecast only pays when it reaches someone who can act
Four days of warning is worth real money, and it is worth nothing at all if it lives on a screen that the crew planner does not open. The people who can act on a disruption forecast are working inside crew planning tools, IROPS consoles, station dashboards, and revenue management systems, and most of them are not going to change where they work because a new platform arrived.
Until now, getting S-System numbers into those tools meant an integration project per destination system. Auth, retries, backoff, pagination behavior, and error handling, written once per team and subtly differently each time. That work is identical across every airline that has commissioned it, and it delays the point at which the forecast changes a decision.
The clients ship that plumbing solved, on the two ecosystems airline IT teams already run.
What airlines are wiring it into
Four patterns account for most of the early integrations:
•Crew and aircraft planning. Congestion and delay signals delivered into the planner’s own tool, so a rotation can be protected before the day turns.
•IROPS consoles. Station-level congestion with its one hour and three hour forecast alongside the rebooking screen, so the desk sees pressure building instead of reacting to the queue.
•Station dashboards. Airport overview, stand utilization, and gate conflicts pulled into the local dashboard a station manager already trusts.
•Commercial and BI reporting. Route analytics and on-time performance pulled into the warehouse, so the monthly pack stops being a manual export and starts being a query.
Numbers that survive an audit, in your code as well as ours
The two properties that make S-System figures defensible carry straight through the clients.
Every record declares its provenance. Each flight carries a confidence marker reading live feed, database, or generated. A generated record exists so a page is never empty, and it is labeled rather than presented as an observation. In TypeScript that marker is a narrowed union, so a misspelled comparison fails to compile instead of silently never matching. Filter on it once at your ingestion boundary and everything downstream is observed data.
Denominators travel with the percentages. On-time performance is calculated over the flights that actually reported times, and the measured count comes back in the same response. Nulls stay null, so an unreported delay is never quietly counted as zero. An analyst can audit any figure you publish rather than taking it on trust, which is the difference between a number you can put in a regulatory filing and one you cannot.
Your integration team gets that discipline for free instead of reimplementing it per project.
Your plan is readable, so your tools can respect it
Capability follows your subscription, and the platform tells your code what it holds. Your subscription record exposes the feature codes on your account, so an internal tool can hide what your plan does not cover instead of showing an operations manager a button that returns an error.
When a call does hit something you have not licensed, the response is an explicit plan-required signal rather than a generic failure. That routes the question to your account manager instead of your engineering backlog. Sustained and burst rate limits follow the plan as well, and the client reads them rather than hardcoding them, so an upgrade takes effect without a code change. Plan contents are on the pricing page.
Passenger intelligence continues to be delivered through the application and through scheduled data delivery. Direct integration access is arranged through your account manager.
Five minutes to your first prediction
# Python (3.9 or newer) pip install kquika-ssystem # Node / TypeScript (Node 18 or newer, types included) npm install @kquika-inc/s-system #Python from ssystem import AuthenticatedClient from ssystem.api.flight_operations import list_flights client = AuthenticatedClient( base_url="https://www.s-system.cloud", token="sk_live_your_key_here", auth_header_name="X-API-Key", prefix="", ) with client as c: res = list_flights.sync(client=c, origin="SDQ", limit=25) for f in res.data.flights: print(f.flight_number, f.origin, f.destination, f.data_confidence)
Every operation has an async form in Python, every schema is exported in TypeScript, and both clients are MIT licensed.
Start building
Python package: kquika-ssystem on PyPI
Node package: @kquika-inc/s-system on npm
Full API reference: s-system.cloud/document
An API key, a plan change, or a capability your plan does not carry: www.s-system.cloud
License: MIT
S-System already forecasts disruption four days ahead of the schedule your crews are working to. As of today, that forecast reaches the tools where the decision actually gets made, with every row labeled so you know exactly what you are planning against.
