Grip anchors the event app, registration and meetings for 5,000+ events and 15m+ participants. Its matchmaking is generated from registration fields and self-declared interests. Pirida builds the profile from the outside — 12+ public signals — then runs double opt-in and books the meeting. This brief maps exactly where the two stack.
Grip (Intros.at Ltd, London; $13m raised) is not the closed black box its marketing site suggests. Its API is live, versioned and documented — but access is granted per-partner, not self-serve. Everything below was verified by probing the live endpoints, not read off a datasheet.
| Interface | What it is | Auth | Status |
|---|---|---|---|
| Events API | api.grip.events/v1/* — the base of the platform. One LB also answers as api.intros.at. | Bearer token, issued in the dashboard | partner-gated |
| MCP gateway | gateway.grip.events/mcp — streamable HTTP MCP server exposing 6 read-only tools over live event data. | OAuth 2.0, dynamic client registration | public discovery |
| Registration push | /thing/register — POST a registration record; the write path partners use to load a list. | Dashboard token | partner-gated |
| SSO | SAML 2.0, OIDC and OAuth 2.0. SP metadata and assertion endpoints under api.intros.at/sso/saml2/… | IdP-signed assertions | documented |
| Native integrations | A first-party sync engine: filters, field mapping, modifiers, scheduling, 30-day logs. | Provider credentials + IP allowlist | self-serve |
| Data model | Application (app / workspace) → Container (one event) → Thing (a person, company or item). | — | stable |
An application holds many events; a container is a single event, addressed by a numeric id. The API's own field groups cover must_meet_config, meetings_config, cpf_config and native_integrations — matchmaking configuration is a first-class, readable object.
Grip's pre-scheduled meeting engine has its own config, its own provider API keys and its own analytics dataset. It expects selections from delegates and turns them into a schedule — Pirida can supply those selections from a much richer profile than the registration form.
Eleven datasets — event health, people & teams, meetings, MustMeet, lead gen, sessions, app usage, search, content & floorplan, custom profile fields, advertising — queried with read-only SQL, results capped at 500 rows.
The gap Pirida fills: every input Grip matchmaking receives is self-declared or registrar-supplied — job title, company, a few custom profile fields. Pirida's inputs are observed: talks, podcasts, filings, hiring and funding signals, post history. Grip scores who the system already knows about; Pirida scores who is actually worth meeting.
The integration is mostly plumbing — with a genuine architectural decision at the end. Here is what Grip can hand over, what Pirida returns, and where the boundary should sit.
| # | Direction | Mechanism | Payload | Use for Pirida |
|---|---|---|---|---|
| R1 | Grip → Pirida | Insights SQL via MCP |
Participant & company records, types, registration ids, meeting and session history | The seed list. Everything Pirida enriches and ranks. |
| R2 | Grip → Pirida | get_container / config fields |
MustMeet config, meeting rules, enablement flags, group membership | Constrains the match — never propose a pair the event can't physically host. |
| W1 | Pirida → Grip | /thing/register push |
Enriched profile: headline, summary, metadata_raw, relationships | Writes the enrichment back so it appears in the app delegates already use. |
| W2 | Pirida → Grip | MustMeet selections needs partner scope | Double opt-in pairs as meeting intent, or a scheduled meeting | The money path. Grip fulfils the meeting; Pirida chose it. |
Registration data reaches Grip through the same /thing/register contract regardless of source — Swoogo, Cvent, HubSpot, or a bespoke registrar. A new push source needs no new platform capability. That makes Pirida a registration integration partner in Grip's own taxonomy, on day one, with an existing role definition.
Nothing in Grip's public surface lets a third party place a scheduled meeting into MustMeet. The MCP is explicitly read-only; the Events API is documented for ingestion, not for orchestrating meetings. Two routes exist — apply for partner scope on the Meeting Provider role, or run the meeting layer alongside Grip and sync outcomes back. This is the one decision to settle in the room.
Recommended architecture: Pirida reads through MCP (sanctioned, permission-mirrored, no data-copy), enriches privately, writes profiles back through /thing/register, and hands the delegate a ranked pairing surface. Grip remains the system of record and the meeting venue. Pirida never becomes a competing app.
Each is a distinct commercial motion, priced separately, and each one survives on its own if the next is never bought.
Take the registrant list the moment it exists and build the profile Grip never will.
Instead of an empty grid waiting for delegates to browse, open with ranked candidates.
The renewal problem is a pipeline problem. Solve it before the show floor opens.
The formats Grip sells but doesn't populate: meet-the-buyer, hosted buyer, investor meetings, roundtables.
Turn the event into the evidence that renews the contract.
Grip's 365 Community extends the event; Pirida extends the matchmaking across the year.
Findings from probing the live platform and its documentation. Ranked from fully accessible to requiring a commercial agreement.
The gateway publishes full OAuth 2.0 discovery metadata, and its dynamic client registration endpoint accepts unauthenticated registrations. A client can be registered without a Grip account; only the user-facing consent step needs a Grip login. This means an integration can be built and demonstrated without waiting on a partnership, and the delegate's own Grip permissions govern what it sees.
Event health, people, meetings, MustMeet, lead gen, sessions, app usage, search, content, custom profile fields, advertising. Queries are force-scoped to the caller's events regardless of the SQL written. Batch-loaded, so figures lag live activity by hours; configuration reads are live.
POST a full registration record: identity, company, job title, headline, summary, locale-keyed metadata, relationships. Multi-language values are carried per locale. Any registration id containing the literal string admin is silently frozen from updates — a real constraint on id generation.
Grip defines an Implementation Partner Admin with full API access, and a Registration Provider role scoped to API tokens and documentation with GET/POST/PATCH/DELETE on its own data. Both are the sanctioned route to production access, and both are granted through the commercial relationship — not self-serve.
No documented third-party path to place a confirmed meeting into the MustMeet engine. Meeting-related API keys exist for the Meeting Provider role, which indicates the door exists — but it needs partner scope to open. Until then, the meeting layer runs alongside Grip and syncs outcomes back by hand or by export.
Grip sells to Informa, Clarion, Messe Frankfurt and Delinian — organisers whose legal teams will interrogate how delegate data crosses to a second enrichment vendor. Grip's terms name both parties "data processors"; the EU AI Act transparency obligations plus UK/EU GDPR mean the pitch needs a DPA, a stated lawful basis, a sub-processor list and a data-retention position before the first pilot, not after.
The MCP server is reachable with a standard client. Streamable HTTP, OAuth handled on first use.
Grip's API sits behind an AWS eu-west-1 load balancer. That keeps delegate data inside the EU for the read and write paths — a useful fact when the buyer's legal team asks the residency question. Confirm it in writing before relying on it in a proposal.
Each tier attaches to a spend the organiser has already committed. None of them require leaving Grip.
For the organiser who wants better matchmaking without changing platform or app.
For the organiser whose renewal conversation depends on proving sponsor ROI.
For groups running many events a year under one commercial frame.
The wedge argument. Grip already earns on meetings booked — "2m+ meetings" is its headline claim, and pre-scheduled meetings are its fastest-growing product. Pirida does not compete with that revenue; it makes the same meetings more qualified. An organiser who adds Pirida should see their Grip metrics move, which is why this is an easy yes for Grip and an easy yes for the organiser.
These organisations sit inside Grip as registered integration partners with documented data paths. Pirida's route in is the same one.
Informa · Clarion Events · Money20/20 · Messe Frankfurt · Delinian · Forge · SXSW. Enterprise organisers, procurement-led, with real legal review.
ESSA member and UFI associate member. Named technology partner for UFI's European Conference and PCMA Convening Leaders.
Lead with the sanctioned path, not with cleverness. The access already exists, the roles already exist, the contract template already exists. What's missing is a supplier who does the enrichment properly.