The SANS.AI Platform SDK is available today for Python and Node/TypeScript. It covers all 52 publicly callable methods on the platform, from live flight states and LiDAR passenger flow through to delay prediction, turnaround allocation, and custom model training.
This is a distribution release rather than a new capability. Everything the SDK reaches has been running inside SANS.AI for airports already on the platform. What changes today is where the answers can go.
The dashboard is not always where the decision gets made
An operations platform earns its money at the moment somebody acts on it. In practice that moment often happens somewhere else: in the A-CDM platform the tower team already lives in, in the rostering tool a duty manager uses to move staff, in the ground handler’s own system, or in the Monday morning board pack pulled from a BI warehouse.
Every airport that wanted the platform’s numbers in those places used to fund a small integration project first. A token header. A retry loop. Backoff logic. Quota accounting that somebody has to get right or the integration goes dark mid-shift. That work is identical at every airport, it takes an experienced engineer several days, and none of it turns an aircraft.
We wrote it once, for everyone, and it now ships as a supported library on the two ecosystems airport IT teams actually run.
What teams are already building with it
The early integrations cluster into four patterns, and each of them is a case where the recommendation lands in the system of record rather than on a second screen:
•Predictions pushed into A-CDM. Delay probability and expected delay minutes surfaced next to the milestones the tower team already works to, so the forecast arrives inside an existing workflow.
•Passenger flow wired to staff dispatch. Bottleneck severity and dwell time at a security or immigration zone triggering a dispatch in the workforce tool, without a supervisor watching a heatmap to catch it.
•Turnaround predictions feeding resource planning. The FRMS allocation loop connected to the planner’s own tooling, with the decision the planner made written back so the next training cycle learns from the difference.
•Operational data landing in BI. Historical movements pulled straight into a DataFrame or a warehouse, so on-time performance and stand utilization reporting stops being a manual export.
Each of these used to be a scoped project. Most are now an afternoon.
Access you can hand to a third party
The commercially interesting part for airports running a mixed ecosystem is authentication. The SDK supports API keys and OAuth 2.0 client credentials as equal citizens.
That means a ground handler, an airline partner, or a systems integrator can be issued credentials scoped to exactly what their integration needs, such as read access to flights and LiDAR and nothing else. Asking for a permission the client was never granted fails at credential issue rather than at the first live call, so a misconfiguration surfaces during setup instead of during a bank of departures. Nobody has to share a master key to get a partner integration off the ground.
Entitlements are visible, not discovered
Your plan governs what the SDK can reach, and the client reports your position rather than making you find the ceiling by hitting it. Every response carries your remaining daily rate limit and your remaining monthly call allowance, which is shared across every credential your account owns.
Rate limiting and monthly allowance are deliberately separate signals. One clears inside the window and is worth retrying automatically, which the client does with exponential backoff. The other holds until the calendar month turns over, so the client hands it straight back rather than retrying for weeks against a wall.
Turnaround Allocation remains licensed separately from the plan tiers, and the platform returns an explicit access-required response when the add-on is not on the account. Plan contents and allowances are on the pricing page.
Every number that arrives is real
The platform rule that matters most to anyone piping this into an operational system carries through the SDK unchanged. SANS.AI never substitutes an estimated, sampled, or heuristic value for an observation. Where no records or no trained model exist, you get an explicit no-data response instead of a plausible number.
Predictions carry their own confidence and name the model that produced them, so an output in your system can be traced back to a model version. If this feeds stand assignment or crew dispatch, that traceability is what lets you defend the decision afterward, and it saves your team a defensive check on every field.
Five minutes to your first call
pip install kquika-sansai # Python 3.9 or newer npm install @kquika-inc/sansai # Node 18 or newer, types included #PYTHON from sansai import SansAI sansai = SansAI(api_key="YOUR_API_KEY") for flight in sansai.live_flights(airport="LHR"): print(flight.flight_number, flight.status, flight.delay_minutes)
Live flights come back nearest first, safety alerts most severe first, and bottlenecks worst first, so planning code starts at index zero. Errors are typed, so an integration can catch the case it cares about rather than parsing status codes.
If your stack runs on Go, Java, or C#, the platform serves its own OpenAPI specification and a client can be generated from it, so the contract you build against is always the one the service is running.
Start building
Python package: kquika-sansai on PyPI
Node package: @kquika-inc/sansai on npm
Full API reference: sans-ai.tech/documentation
Credentials, scoped partner access, or a raised limit: support@kquika.com
License: MIT
SANS.AI already tells operators where the next hour goes wrong. As of today, getting that answer into the systems your teams actually work in takes less code than reading this post did.
