Third parties connect only when you say so, and you can switch them off at any time.

External integrations are configured by you, scoped per facility, and can be enabled or disabled at any time. Performance Hub provides and vets the mechanism; the relationship with any partner, and what they do with the data they pull, is between you and them.

• External integrations are configured in the platform's External Integrations settings, per facility.
• Each integration is enabled or disabled per facility, and you can change that at any time. Disabling an integration stops new data flowing; data already synced is governed by your retention and deletion controls.
• Partner access is off by default for a facility until you enable it. A partner cannot push data to, or act on, a facility that has not enabled them.
• Secret integration credentials are stored in your configuration and masked when read back.

Approved partners integrate through the Performance Hub Partner API, a versioned, HTTPS-only, authenticated surface.

What a partner can push into the platform

• People records (identity, contact, access status and plans, optional profile photo).
• Access plans (entitlements, access zones, access hours).
• Check-ins (attendance records).
• Operational/financial report snapshots.

What a partner can read or trigger

• The organisations and facilities linked to them.
• Door/Gate controller status, and a synchronous door-unlock command with physical relay confirmation.

Controls on the mechanism

• Authentication is by API key (HTTP Basic), with live, dry-run and read-only key types. Keys can be rotated and revoked instantly, with per-key last-used visibility.
• Rate limits apply by default (per-endpoint request rates, batch sizes, payload caps).
• A partner only acts on facilities where the integration is enabled; requests against a disabled facility are rejected, and people syncs to disabled facilities are skipped, not stored.

Who owns the access decision depends on which application is making it.

• Standalone, through our Door & Gate Access app. Performance Hub provides the full access-control logic - access status, access hours, door-zone rules and geofencing. This applies even when a partner has only synced person and access data into Performance Hub: if the customer operates the doors through our app, those rules are ours to enforce.
• Partner-integrated, through the partner's own product. When a partner has built door/access control into their own app and calls the unlock API, their system is the authority for whether a person is allowed to enter and evaluates its own access status, hours, rules and fraud/suspension logic before calling us. In that mode Performance Hub verifies the partner key, facility access, door ownership and device state, and operates the controller hardware, but does not re-evaluate the partner's access decision.

In both modes Performance Hub makes the door-control hardware and the secure command path. The difference is who decides who may enter: our app when run standalone, or the partner's system when they have integrated access control into their own product - and that decision, and its lawfulness, sits with whoever owns it.

• People and check-in data pushed by a partner is stored per facility and used to drive features like door access-zone rules and people analytics.
• Sync overwrites only the synced fields (name, contact, type, access status); your admin-owned data (access switches, grants, custom tags, notes) is never overwritten.
• Right-to-be-forgotten. If a person still exists in your source system of record, a future sync can recreate their profile. A genuine deletion request must be actioned in the source system first, then in Performance Hub.

Beyond named partners, you can connect your own software and AI agents to the platform through APIs and the Model Context Protocol (MCP).

• Scoped keys. Access uses personal API keys or OAuth, scoped to what you grant. A key can never see more than its owner could in the UI.
• Two kinds of MCP access. *Per-user MCP access* is tied to a person's own account and is used to connect third-party agents such as Claude or Cursor (see the docs for connecting external agents). *Per-agent service-account access* is configured on each Performance Hub agent device, independent of any individual user's roles - so an agent's access is stable when a user's roles change or the user is removed.
• Grant attenuation. You can only grant scope you yourself hold. Organisation-wide scope requires an organisation-level admin.
• Central enforcement. Every call is checked against the access you have granted, on the Performance Hub side, not on trust.
• Instant revocation. Toggle access off and it stops within moments; removing a device revokes its credentials immediately.
• Key hygiene is yours. Treat API and MCP keys like passwords: scope them to service accounts where possible and rotate them when staff change.

Performance Hub provides and secures the mechanism

• The Partner API, authentication, key types, rate limits, per-facility enablement enforcement, and partner request logs.
• The secure door-unlock command path and controller hardware.
• Central, server-side enforcement of API/MCP grants and tool permissions, and the credential-revocation paths.
• Partner onboarding and vetting (sandbox testing and a going-live checklist before production access).

You are responsible for the decisions

• Choosing and managing each partner relationship. You enable the integration; you can disable it at any time. Performance Hub vets partners before production access, but the enable/disable decision per facility is yours.
• What partners do with the data they pull. Performance Hub is not responsible for how a partner handles data once it is in their system. That is governed by your agreement with them.
• Any API or MCP integration you enable. The same rule applies: we provide the secure, scoped mechanism; how the connected system uses the access you grant is your responsibility.
• Access decisions at the door. Your partner's system is the authority for who may enter.
• Source-of-truth data quality and lifecycle, including actioning right-to-be-forgotten requests in the source system.