Your stack should not decide your event platform
A checklist is a snapshot. An API is a capability. The difference shows up the day you need to connect something nobody put on a roadmap.
Adis Jugo
CEO
Published · 6 min read
Open API
A checklist is a snapshot. An API is a capability.
The tools that matter most to your team are often the ones no vendor will ever put on a roadmap. Those are exactly the ones worth asking about.
A few weeks ago we wrote about why integration lists are a poor way to evaluate an event platform. This is the other half of that argument, and it is less about philosophy than about what happens when somebody has six weeks to make two systems talk to each other.
The scenario that decides this
You are not evaluating platforms in the abstract. You are three weeks from launching registration and your membership database has to stay in sync with the event, because members get a different price and the finance team will not accept a manual reconciliation afterwards.
That database was built in-house. It has an API of sorts, written by someone who left in 2022. It is not on anybody’s integrations page and never will be, because there is exactly one organisation in the world that uses it: yours.
This is the actual integration problem. Not Salesforce. Not the connectors everybody already has. The awkward, specific, locally critical system that your organisation has built its processes around.
Why the checklist fails you here
A vendor builds native integrations for the tools that most customers ask for. That is rational, and it means the list skews toward large, popular, horizontal platforms.
The result is that the integrations page is most comprehensive exactly where you need it least, because those connections are commoditised, and emptiest exactly where you need it most. The more specific and load-bearing a tool is to your organisation, the less likely it is to appear.
Which is why “does it integrate with X” is the wrong question. It is one of the common mistakes when choosing event technology. The better one: if it does not integrate with X, what happens then?
There are three possible answers. It goes on a roadmap, which means it happens when enough other customers want it, which for a tool only you use is never. You pay for custom development work as a project. Or there is an open API and the connection is something you or we can build without anybody’s permission.
Only the third one is a capability. The other two are a queue.
What open actually means
run.events is built on an open API. Your developers can work against it directly. So can ours. So can a contractor you bring in because they wrote the original membership database and still answer the phone.
That changes the shape of the conversation. Instead of “is it supported,” the question becomes “what does it take,” and that has an answer measured in days rather than quarters.
It also changes who holds the risk. If your connection depends on a vendor’s roadmap, your timeline depends on their priorities. If it depends on an API you can read the documentation for, your timeline is yours.
The same applies when you switch platforms: our Platform Migration service brings your data across from the old system’s exports or APIs, and these five steps show how to plan the move.
And the newer part: assistants, not just systems
There is a second kind of integration that barely existed two years ago and now comes up in most technical conversations we have.
Every event running on Smart Hub is automatically an MCP server, with no setup. That means the AI assistant your organisation already uses can connect to your event data and work with it directly, rather than you waiting for an event platform to build its own assistant and hoping it is good.
Our agents, part of the Event Intelligence Cloud, also speak A2A, the open Agent-to-Agent protocol, so they can work with other compatible agents rather than only among themselves.
The principle is the same as the API one. We are not trying to predict which tools you will use. We are trying to make sure that whatever you choose can reach your data.
Questions worth asking any event platform
- If the tool we need is not on your list, what happens? Roadmap, paid project, or open API. The three answers are not equivalent.
- Can our own developers build against it? Or does every connection have to come through you?
- Where is the API documentation? Public docs are a decent proxy for whether “open” is real.
- Can an external AI assistant reach our event data? Increasingly the integration that matters most.
The thread running through this month
We rebuilt community.run.events so you can find an answer without opening a ticket. We are running a survey rather than sending a pitch. And the integration story is the same idea in a different place: meeting you where you already are instead of asking you to move.
Nobody wants to rebuild their stack around an event platform. The platform should be the thing that adapts.
Bring us the difficult one:
The tool nobody else would connect to is the one worth talking about.
Come with the awkward system, not the easy one. You will learn more about the platform in ten minutes that way.
