Contents

Integrations and webhooks - Plugixa CRM

The integrations framework is free. Every connector except webhooks is paid. That sounds backwards until you look at what is in each.

The Integrations screen, with a card per connector showing whether it is installed, connected and enabled

What the free edition actually ships

Not “the ability to buy connectors”. The whole machine:

  • The screen, with a card per connector.
  • The credential store, encrypted with a key derived from your site’s own security keys.
  • The job queue, so a connector’s work happens on cron rather than in the request that triggered it.
  • Health checks, per connector.
  • The field mapping interface.
  • Webhooks, which is a fully working connector.

What it does not ship is the other five connectors’ code.

A locked card is an advertisement, not a switch

This is the part worth being precise about, because it is easy to do badly.

A connector that is not in your download appears as a card that says so. It does not appear as a greyed-out switch you cannot move, and its routes answer 404 rather than “upgrade to continue”.

The copy on those cards says it plainly: these are not part of this download, and adding one installs its code. Nothing here is switched off waiting for payment.

The precedent is a sibling plugin that once shipped a visible Import/Export dialog whose three routes all lived behind the paywall: every option in it returned a 404 on the free build. That is what this arrangement exists to avoid.

Enabling and disabling

An installed connector has a real on/off switch, and it really works: switching WooCommerce off stops orders syncing.

That was not always true. The switch used to be a chip that recorded a state no work path consulted, so “disconnecting” WooCommerce changed a label while the shop went on syncing every order. It is now checked where the work happens.

Webhooks

The webhooks screen, listing endpoints, their events and their recent deliveries

Tell another system when something changed here. Point one at Zapier, Make, n8n or your own server.

A webhook names the events it wants and the URL to post to. Deliveries are queued and drained on cron, with retries, so a slow or briefly unavailable endpoint does not slow down the person who saved the record.

Test sends one immediately, which is the one deliberate exception to the queue.

There is also a secret, so the receiving end can verify the request came from you.

The Webhooks connector panel, where the endpoint, its events and its secret are configured

The address is checked twice

An outbound webhook is a request your server makes to an address somebody typed. That is the classic way to reach things that are not meant to be reachable: internal services, cloud metadata endpoints, anything on the local network.

So private and reserved addresses are refused on save, and checked again before every request. Twice, because DNS can change between the two: an address that resolved publicly when it was saved can resolve to an internal one later.

Webhooks are deliberately not part of the role matrix

Configuring them needs the WordPress manage_options capability, not a CRM role.

That is on purpose: no CRM role should be able to grant somebody “make this server post to an address of my choosing”. It is site administration, not record work.

Webhooks is also the hidden route in the app - reachable and absent from the sidebar - for the same reason: it is not a screen most people need.

Where the premium connectors appear

None of them has a sidebar item. Each surfaces in one of three places:

Connector Appears as
Contact forms An Integrations card
Google Calendar An Integrations card
Microsoft 365 An Integrations card
Twilio A panel on a contact’s own record
WooCommerce A panel on a contact’s own record

Troubleshooting

Symptom Usual cause
A card says it is not installed It is not in this download. Free ships the framework and webhooks.
A connector route returns 404 Same reason. The code is absent, not refused.
Disabling a connector changed nothing It should stop the work. Report it if not; this was once a real bug.
A webhook URL was refused It resolves to a private or reserved address. That is the guard working.
A webhook worked once and now fails The address is re-checked before every request. DNS may have moved.
Deliveries are slow They are queued and drained on cron. Test sends immediately.
A CRM role cannot manage webhooks Correct. They need manage_options.
Webhooks is not in the sidebar It is a hidden route. Reach it directly.

What to do next

Quick Links