Why "we integrate with everything" usually means five tools

You know the moment. You are comparing event platforms, you get to the integrations page, and there is a wall of logos. Looks comprehensive. Then you scan it for the one system your team actually lives in — the CRM you have had for nine years, the finance tool your controller refuses to give up, the in-house database somebody built in 2019 that nobody fully understands but everybody depends on.

Not there.

So you ask the sales rep, and you get the answer everyone gets: it is on the roadmap.

What a logo wall actually tells you

An integrations page is a snapshot of what a vendor has already built. That is useful information, but it is not the question you are really asking. The question is whether this platform can connect to your stack, which is a different thing entirely, and a logo wall cannot answer it.

Here is the uncomfortable part. Most integration lists are long because they count every direction of every connection separately, or because they include things that are really just a webhook with a logo attached. Strip that back and a lot of platforms are genuinely deep on maybe five tools, shallow on another dozen, and silent on everything else.

That is fine, as long as your stack happens to be those five tools. If it is not, you end up designing your entire event process around a gap between two systems, which usually means somebody exports a CSV on Friday afternoon.

The integrations we have built

run.events connects to whatever your organisation already runs: your CRM, your finance and accounting software, membership databases, marketing tools and your own internal systems. For the tools most organisers use, those connections already exist. Everything else is connected through the same open API when an event needs it, built by our team or by yours.

What makes that possible is the part worth understanding.

What sits underneath: an open API

run.events is built on an open API. Not a partner programme you apply to, not a closed system with a few approved doors — an actual API that your developers or ours can build against.

The practical consequence: when the tool you need is not on the list, that is a conversation rather than a no. Sometimes we build it. Sometimes your team does, because they know their own system better than we ever will. Either way, the answer is not “wait for the roadmap.”

That distinction matters most for the connections no vendor will ever prioritise. A regional ticketing provider with four hundred customers. An internal membership database. A finance system your organisation has committed to for the next decade. None of those will appear on anyone’s integration page, and all of them are completely connectable.

We look at that case, the in-house system with three weeks to go, in Your stack should not decide your event platform.

For the technical side, our API & Integration page explains what the API covers and how a connection gets built.

The 2026 version: your AI assistant can talk to your event

Here is where the integration conversation has quietly changed, and most of the industry has not caught up yet.

Every event running on Smart Hub is automatically an MCP server. No configuration, no setup step, no separate product. MCP, the Model Context Protocol, is the open standard that lets AI assistants connect to external systems and work with them directly.

What that means in practice: the AI assistant your team already uses can connect to your event data and work with it. Ask it about registration numbers, session capacity, sponsor commitments, whatever lives in the event. You are not waiting for us to build a chatbot into our own interface. You are using the tool your organisation already chose, pointed at your own data.

On top of that, our agents, part of the Event Intelligence Cloud, speak A2A, the open Agent-to-Agent protocol, so they can communicate with other A2A-compatible agents rather than only with each other.

This is not a feature we bolted on to look current. MCP and A2A are architectural primitives in how the platform is built, which is why every event gets it automatically rather than as a premium add-on.

What this is worth on an ordinary Tuesday

None of this is interesting as architecture. It is interesting because of what it removes from your week.

Fewer CSV exports. Fewer people retyping attendee data from one system into another and introducing a typo somewhere in row 340. Fewer processes that exist purely to bridge a gap between two tools that should have been talking to each other.

And one less category of question during procurement, the one where you are trying to work out whether a platform will still fit your stack in three years, when you will have swapped out at least one system and inherited two more.

A platform built on an open API does not need to predict which ones.

Tell us what is in your stack and we will tell you honestly what connects today, what needs building, and roughly what that takes.