For nearly a decade, Lumo’s API has helped companies build better ways to predict, understand, and...
Innovation is often a race between ideas and engineering. In travel technology, there is another factor that matters just as much: access to the data that makes those ideas useful.
Great data can sit behind a commercial process that makes experimentation too expensive. Good product ideas can remain on a roadmap because the cost of testing an integration is difficult to justify. The result is not a lack of ambition. It is friction.
That is what we set out to remove when Lumo released its self-serve API and MCP access, following our earlier announcement, Lumo’s Travel Intelligence Is Now Self-Serve.
From release to working integration in a weekend
Lumo released the portal on Friday morning in the United States. On Saturday morning in Europe, TripActivity provisioned an API key and began working through the REST API, MCP server, and documentation.
Within a few hours, TripActivity had a working proof of concept. A few hours after that, the integration was running across two parts of the product: the corporate-travel dashboard and itinerary emails.
By around 8 a.m., the team had validated the API against its own flight data. By midday, the first real delay-risk prediction was flowing through the pipeline. An on-screen risk indicator followed in the early afternoon. By approximately 3 p.m., the finished experience—per-flight delay risk and missed-connection risk—had been verified in the web application and included in traveler itineraries.
From opening the documentation to the first live result, the initial path took roughly four hours. The broader pilot integration was completed in a single working day.
Fast does not mean trivial
It is important not to confuse speed with simplicity. TripActivity still had to make the product decisions, understand the data, build the integration, connect it to its own flight records, design the user experience, test the results, and release the feature safely.
That is real engineering work. The point is that the team could spend that time building the product rather than waiting for access, negotiating a separate commercial arrangement, or creating a business case for a speculative proof of concept.
As Riaan put it:
“From reading the Lumo docs to live delay-risk and missed-connection indicators in our dashboard and our itinerary emails—in a single working day, about four hours to the first live result. Their clean REST API and broad coverage made it genuinely quick to integrate.” - Riaan van Schoor, Co-Founder, TripActivity & Agentivity
What becomes possible when the walls come down
Before self-serve access, an integration like this would likely have required several conversations between the companies, a product discussion, commercial negotiations, API provisioning, usage monitoring, and a decision about whether a proof of concept justified the cost.
Those steps may be appropriate when a customer is ready for a large-scale deployment. They are not always appropriate when a small team is simply trying to answer a question: Can this data make our product better?
Self-serve access changes that equation. A team can start with a real use case, validate the value, and then scale when the product is ready. It lets the engineering conversation begin earlier, when the most important question is still whether an idea works.
In TripActivity's case, Lumo’s predictions are now available where users can see them: alongside the flights in an itinerary and inside the workflow used to manage corporate travel. A user can see that one segment carries elevated delay risk, understand whether a connection is likely to hold, and make a better-informed decision before a disruption becomes a missed connection.
That is the larger opportunity. Lumo contributes travel-intelligence data and predictive signals. TripActivity contributes a product, a workflow, and a clear idea of how that information should be used. The connector is what allows the two to become useful together.
The connector is part of the product
In an AI-first ecosystem, the quality of the answer depends on more than the model. It depends on the quality of the data, the clarity of the interface, and the ability to place the result inside a real workflow.
APIs and MCP servers are not just technical plumbing. They are how specialized capabilities become available to other products. They allow a travel platform to ask whether a flight is at risk, whether a connection is likely to be missed, or whether a traveler needs attention—and then turn that answer into an experience for a person.
The faster those connections can be made, the faster good ideas can be tested in the real world.
We think this is an early example of what becomes possible when data providers make access practical and product teams are free to experiment. The outcome was not “AI for AI’s sake.” It was a focused use case, built quickly, that helps people see potential problems earlier and act on them.
Also: This blog post was authored by ChatGPT Work using HubSpot connectors, based on input from Bala and Riaan—another example of how connectors make all the difference.
