Integrations & connectors · the platform

Plug into what you already run.

25+ official connectors and 1,200+ executable actions. The AI works from real platform data and can take action — with your approval. Categorised, live-status flagged, signed and sandboxed, with a clean pattern so you can build your own in an afternoon.

25+ connectors1,200+ actionsHMAC-signed webhooksNo-code builder
🔐 HMAC-signed
↔ Bidirectional sync
Live Every system. One AI core. 💳🏢🛒💬📧🧠 OpsIQAI CORE
Integrations & connectors

Your data. Your install. One AI brain.

OpsIQ connectors run where your platform already lives: inside your own install, self-hosted or cloud. They pull live context, expose approved actions, verify packages, and keep every signal flowing into the same AI behind chat, tickets, CRM, analytics and promotions.

Billing Commerce Support Webhooks Identity AI providers OpsIQAI CORE
37+connectors across billing, commerce, support, AI and identity
1,200+actions exposed to the AI with approvals and audit trails
Signedtrusted manifests, integrity checks and upload safety scans
Two-waycontext in, approved action out, events mirrored back
Native architecture

Not a marketplace bolt-on. Part of the platform.

A third-party hub turns your customer data into rented traffic. OpsIQ flips the route: connectors sit inside your install, talk directly to the systems you already run, and become first-class AI context, actions, audience signals and audit events.

Vendor hubmetered runsdata leaves your control
OpsIQ installdirect routecontext, action, identity, events
Your storeYour billingYour siteYour helpdesk
connectors/your_platform/connector.php
contextProviders() registerActions() identityProviders() subscribers() handleWebhook()
Under the hood

One folder. One contract.

A connector is discovered when its folder lands in place. Implement the methods your platform supports; OpsIQ wires the admin UI, AI action contract, events, webhooks and identity layer without changing core code.

Live context inreal platform records inside the AI prompt
Safe operations outrole-gated actions with confirmations
React & receiveevent subscribers and inbound webhooks
Zero UI codesettings.json renders the admin controls
No-code builder

Build a connector in six steps.

The in-app builder walks through identity, auth, test, actions, triggers and review. It keeps testing until the connection returns a clean 200 OK, then generates a signable connector folder.

01Identity
02Auth
03Test
04Actions
05Triggers
06Review
Connector BuilderStep 3 / 6
TEST CONNECTION base_url: https://api.platform.com auth: Bearer •••••••• Connected · 200 OK Generates connector.php + settings.json + actions.json
Data in, actions out

Bidirectional by design.

Inbound email and webhooks become real work. Outbound events stream out signed. Every retry, identity decision and action can be audited back to the source.

IN

Email in. Native ticket out.

Point a mailbox or JSON webhook at OpsIQ. Messages are thread-matched, create-or-append, and attachment-aware.

support@acme#4821 · Refund?Assigned
OUT

Every event streamed signed.

Register an external system to receive HMAC-signed events with automatic retry, delivery logs and idempotency.

contact.upsertedsha256200 OK
Reference connector

WHMCS, fully wired.

The WHMCS Bridge is the reference for depth: customers, services, invoices, tickets, attachments, identity resolution, AI actions and audience flags all moving through one connector.

Set up the WHMCS Bridge
WHMCScustomers · services · invoices
OpsIQ AItickets · actions · audiences
Supply-chain safety

Signed manifests. Sandboxed installs.

Require a trusted OpsIQ signature before install, re-verify installed connectors against their manifest, and reject dangerous uploaded packages before files touch your server.

Require-signedblock untrusted packages
On-demandhash and integrity re-checks
Static scanreject eval, exec and system calls
Audience capability

Connectors that target.

Any connector can publish an audience catalog and resolve flags for a known visitor. Promotion Studio reads those flags to target real platform state, fail-closed.

Explore promotions
WHMCS flagaudienceFlags()Promotion StudioWin-back offer
What every connector can do

A shared capability surface.

Every connector duck-types the same contract. Implement only what your platform supports, and the matching capability lights up automatically.

01

Context providers

Live platform data inside the AI prompt.

02

Universal actions

Platform operations with role gates and audit logs.

03

Identity resolution

Map anonymous visitors to real customers.

04

Event subscribers

React to platform, CRM and promotion events.

05

Bidirectional sync

Backfill records, poll and receive webhooks.

06

Ticket mirroring

Pull and push replies with attachments.

07

Audience flags

Publish targeting signals for promotions.

08

Security sync

Share blocked-IP and risk state.

The connector catalog

Every system, already wired.

Official connectors follow one contract and stay grouped the way teams actually search for them, with live and coming-next signals visible at a glance.

Billing & payments

10

Hosting & client billing

2

eCommerce

7

CMS & sites

2

Communication

5

AI providers

5

Identity & auth

2
Ship your own

Build your own — or skip the build.

Use the deep native path when you want a full connector. Use the universal API plus inbound and outbound webhooks when a lighter integration gets the job done in hours.

connectors/your_platform/
connectors/your_platform/
├─ connector.php       // extends AbstractConnector
├─ actions.json        // action contract manifest
├─ settings.json       // admin config schema
└─ ContextProvider.php // live data → AI prompt
Skip the build

Use the universal API.

REST endpoints, inbound webhooks and outbound signed events cover most custom integration jobs without a native connector.

Read API docs
⚖️ How it compares

Native connectors vs a third-party hub.

What an in-platform, AI-native connector gives you that a bolt-on integration marketplace never will.

CapabilityThird-party integration hubOpsIQ connectors
Live data feeds the AI promptContext providers, grounded
AI runs platform actions (with approval)Manual / Zapier steps1,200+ universal actions
Where your data flowsThrough a vendor hubDirectly between your systems
Runs on a self-hosted install
Build your ownLimited / paid tierNo-code wizard or one PHP class
Supply-chain safetyVariesSigned manifests + static scan
Bidirectional ticket mirroring (+ attachments)Email forwardBoth ways, native tickets
Audience targeting from billing stateaudienceFlags() → Promotion Studio
Per-event pricingMetered task runsIncluded with the platform
Common questions

Connectors, answered.

Everything teams ask before they wire OpsIQ into the systems they already run.

Yes. A connector is one PHP class in a folder under /connectors/<slug>/. You can scaffold it with the no-code Connector Builder (six guided steps) or write it directly — implement only the methods your platform needs, like contextProviders(), registerActions() and handleWebhook(). OpsIQ discovers the folder automatically and renders the admin form from your settings.json. Most connectors are 200–400 lines.
You can require a trusted OpsIQ signature for every install, and re-verify installed connectors on demand against their signed manifests to catch on-disk tampering. Uploaded zips also run through a static safety scan that rejects dangerous calls like eval, exec and system before anything is written to disk.
Billing & hosting, payments, eCommerce, CMS, communication, identity and every major AI provider. If yours isn't listed, you can build it or request it.
Where the platform allows it, yes. Connectors stream live context into the AI, run actions back on the platform, backfill historical records, poll or receive webhooks for ongoing changes, and mirror tickets both ways — including attachments.
Yes. Connectors run on your OpsIQ install whether it's self-hosted or cloud. Data flows directly between your systems and your install — not through a third-party hub.
Outbound webhooks are HMAC-signed over the raw body, and inbound requests are verified the same way. Failed deliveries back off and retry automatically, and idempotency keeps retried deliveries from double-acting.
A connector is the deep, native path. The REST API plus inbound/outbound webhooks is the lighter path that covers almost any use case in a few hours.