DEV Community: Themesic Interactive

CRM Contact Limits: How Per-Contact Pricing Taxes Growth

Themesic Interactive — Tue, 25 Aug 2026 00:01:02 +0000

A marketing agency imports 8,000 leads from a trade show, a partner list and last quarter's Facebook campaigns. Nothing about the business changed - same team, same clients, same software. The next invoice is higher anyway, because the database crossed a pricing band. That is the quiet mechanic behind much of hosted CRM pricing: CRM contact limits index your bill to the size of your database, so the platform earns more at the exact moment your marketing starts working. This article explains how per-contact pricing works, the behavior it trains agencies into, and what the same ten thousand contacts cost when the database sits on a server you own.

One disclosure before the argument: we build and sell LeadHub, a self-hosted multi-tenant SaaS CRM with no contact meter pointed at its owner. We are a vendor with a position here - weigh everything that follows accordingly.

How CRM contact limits actually work

Hosted CRM and marketing platforms bill on some mix of three meters: seats, usage and contacts. Seats you choose. Usage you can throttle. Contacts are the meter that grows without anyone deciding to spend, because every form fill, ad lead and imported CSV row moves it.

The mechanics repeat across the industry, so we will describe them as common patterns rather than claims about any single vendor:

Tiered bands. Pricing pages commonly ladder plans by contact count - 1,000, 5,000, 10,000, 25,000 and up - with the monthly price stepping at each band. Your plan is not a price; it is a range you are allowed to occupy.
Tier cliffs. Contact number 10,001 does not cost one contact. It costs the jump to the next band, which can add a meaningful chunk to the monthly bill for a single record. The cliff is why teams start watching the counter in the first place.
The "marketing contacts" pattern. Several popular platforms distinguish contacts you actively market to from records you merely store, which softens the meter but creates an accounting job that did not exist before: someone now curates which humans count as billable.
Dead weight that still bills. On some platforms, unsubscribed and hard-bounced records continue to occupy a slot until you delete them. You pay to store the proof that someone asked you to stop.

None of this is hidden - it is printed on the pricing page. What the pricing page does not spell out is the compounding: a per-contact bill is a recurring tax on database growth, assessed monthly, forever. If your capture works, the CRM price increases with contacts by design. The platform's revenue model and your growth are the same curve.

The incentives per-contact pricing creates

A meter changes behavior, and the contact meter changes it in ways that quietly work against the marketing it is attached to.

The renewal purge. Teams delete cold leads before the renewal date to drop back under a band. It feels like hygiene. It is actually data destruction on a billing schedule: the deleted record takes its activity history with it - the source, the campaign, the three replies from 2024 - which is precisely the data that would later tell you which channels produce buyers.

Selective capture. When every import moves you toward a cliff, leads start staying where they landed - in the ad platform's CSV export, in a spreadsheet, in someone's inbox. The CRM stops being the single source of truth because the single source of truth is billed by the row.

Nurture becomes a luxury. Long-cycle leads - the prospect who buys in eighteen months - are exactly the records a per-contact meter prices you out of keeping. The pricing model votes for short-term pipelines.

To be fair, contact metering is not how every platform charges. GoHighLevel, the dominant agency platform, is commonly described as including unlimited contacts on its plans as of mid-2026 - check their current pricing page - with the growth-indexed part of the bill arriving instead through usage rebilling for email, SMS and calls on top of the subscription. Different meter, same structure: in the hosted model, some counter somewhere rises with your activity, because that is how SaaS database pricing recovers the cost of hosting your data - plus margin.

Pricing structure	What moves the bill	What it trains you to do
Per-contact tiers	Database size	Delete records, capture less
Subscription plus usage rebilling	Messages and minutes	Watch the wallet, throttle volume
One-time licence plus your own hosting	Server resources	Keep everything, clean deliberately

What the next 10,000 contacts cost on a server you own

Here is the arithmetic the tier model obscures. A contact is a database row. Even a rich one - custom fields, tags, UTM data, a full activity timeline - is measured in kilobytes. Call it a generous 100 KB per lead with history, and ten thousand contacts land around 1 GB of storage. MySQL has comfortably handled tables with millions of rows on modest hardware for two decades. On a server you own, the marginal cost of the next ten thousand contacts is, to a first approximation, disk space - and disk space is the cheapest thing in computing.

This is the structural case for an unlimited contacts CRM that you host yourself, and it is worth being concrete about what that looks like in practice. LeadHub runs on PHP 8.4 or higher with MySQL 5.7+ or 8.x, and installs through a browser-driven installer built for ordinary and shared hosting - no SSH, no Composer. Bulk CSV import maps spreadsheet columns to your own custom fields, and there is also copy-paste bulk add for the quick jobs. Import 500 leads or 50,000: the licence cost is identical, because there is no meter to move. You buy the software once; the recurring cost is whatever your host charges for the server, which grows with data slowly and linearly - no cliffs.

The honest counterweight: hosting is a real cost and a real job. A capable VPS commonly runs somewhere in the tens of dollars a month, you are responsible for keeping it up, and backups are yours to run - LeadHub ships verifiable, downloadable database backups, but pressing the button is on you. Ownership removes the tax, not the housekeeping.

The real limits nobody bills you for

Removing the meter does not remove every constraint. Three genuine ones remain, and they exist under every pricing model - the difference is that on your own server they are engineering questions instead of invoices.

Database size. Eventually large tables want indexes and tuning. This is boring, well-understood work, and it is a one-time cost per order of magnitude - not a monthly percentage of your success.
Sending reputation. Email deliverability is governed by your domain and your SMTP provider, not your CRM's pricing tier. Blasting 100,000 stale contacts will land you in spam folders no matter who hosts the database. LeadHub's email sequences track opens, clicks and replies, and stop automatically on reply and on won - the design pushes you toward sending less to the right people, which is what reputation actually rewards.
List hygiene. A big database is only an asset if it is clean. This is where hygiene tools matter more than limits ever did: LeadHub's duplicate detection uses configurable email and phone fuzzy matching with a merge workflow that preserves the activity history of both records - deduplication without destroying the past, which is the exact opposite of the renewal purge. The lead scoring engine, driven by field, behavior and engagement triggers, answers "who deserves attention" without forcing you to delete everyone who does not. And automated retention policies purge audit logs on a 180-day rolling window, login attempts after 30 days and webhook events after 90 - the platform does its own housekeeping on compliance data.

Per-contact billing takes these real constraints and replaces them with a fake one: raw count. Size is the wrong metric. Quality is the right one, and no pricing tier measures it.

When contact limits become your product instead of your tax

There is one place where contact limits genuinely belong: pointed at customers, by whoever owns the platform. This is the multi-tenant flip, and it is where the ownership argument stops being defensive and starts being a business model.

LeadHub is a multi-tenant platform, and its super-admin plan builder exists precisely to create plans with per-plan feature gates and per-resource usage limits - lead caps, team seat caps, storage caps - on tiers you design and price. Plan-limit alerts email your tenants as they approach their lead, seat or storage caps, and team-size caps surface a friendly upgrade prompt inside the tenant dashboard. When a tenant outgrows a tier, the upgrade revenue arrives through your own Stripe, PayPal, Razorpay, Paystack or bank-transfer account - not a platform's.

Read that carefully and the point sharpens: contact limits are not evil. They are a monetization instrument, and the entire question is which end of the instrument you are holding. On a hosted CRM, the meter points at you and rises with your success. On a platform you own, you point the meter at your tenants and price the tiers yourself. Same mechanics, opposite side of the table.

A five-minute audit before your next renewal

Open your billing page. Note your current contact count and the band above you.
Price the cliff: next tier minus current tier, times twelve. That is the annual cost of continuing to grow.
Ask the team one question: how many contacts did we delete last year to stay under a limit? Get a number, not a shrug.
Price the alternative honestly: a one-time licence plus twelve months of a VPS, plus the hours you will spend on updates and backups.
Apply the decision rule: if the answer in step 3 is anything above zero, the meter is already editing your marketing - and a database whose growth is free is not a feature upgrade, it is a different relationship with your own data.

Perfex CRM Payment Gateways: Getting Paid Where Your Clients Are

Themesic Interactive — Fri, 07 Aug 2026 07:00:42 +0000

An unpaid invoice is rarely a trust problem. Most of the time it is a friction problem: the invoice arrived, the client meant to pay it, and the way you asked them to pay was slightly more inconvenient than putting it off. Every day that friction survives is a day of your money sitting in somebody else's account.

Perfex CRM ships with the obvious card and PayPal routes, which cover a great deal of the world and quietly fail for the rest. This post is about the rest: what the other payment rails are actually good at, and how to choose without ending up with a checkout page full of buttons nobody clicks.

We build and sell the gateway modules named here, so read this as a map of the terrain rather than a neutral comparison. The reasoning holds whichever module you end up using.

Payments are not one problem

The mistake is treating "accept payments" as a single feature to switch on. There are three genuinely different problems hiding inside it, and they have different answers.

Problem	Looks like	What actually solves it
Recurring revenue	Chasing the same client every month	Direct debit - you pull, they do not push
Regional reach	A client who cannot use your checkout	The wallet or scheme they already have
One-off convenience	An invoice that sits unread for a week	Fewer clicks between the email and "paid"

A card gateway is a good answer to the third and a mediocre answer to the first two. That is the whole reason this category exists.

Recurring billing: stop asking

If you invoice the same clients every month, the biggest win available is to stop asking them to pay. Direct debit inverts the flow: you collect from their bank account on a schedule they authorised once, and the follow-up email disappears from your life.

Two routes, and the right one depends almost entirely on geography.

GoCardless pulls funds from customers' bank accounts and records the payment inside the CRM, handling both one-off invoices and recurring subscriptions. Stripe SEPA Direct Debit does the same against SEPA-enabled bank accounts across the euro area - set it up once and it captures payments in the background.

If you are already on Stripe for cards, the SEPA module is the smaller step: one dashboard, one reconciliation, one set of payouts. If you are not, GoCardless is worth its own look.

The catch with all direct debit is worth saying plainly: it settles more slowly than a card, and it needs a mandate the customer actively agrees to. It rewards relationships that will last a year, not a one-off project.

Regional reach: the client who cannot pay you

This is the failure mode that never shows up in your metrics, because the client does not tell you the checkout did not work for them. They just pay late, or ask for a bank transfer, or quietly go elsewhere.

Mercado Pago is the answer across Latin America, where for a very large number of buyers it is not an alternative to the mainstream option - it is the mainstream option. Skrill sits alongside the methods Perfex already offers, for customers who keep their money there. myPOS collects invoice payments straight into a myPOS account, which matters if that is already where your business banking lives.

The test here is not "is this popular globally". It is "do I have clients in this market", and if the answer is yes, one gateway that fits them beats three that do not.

Crypto: a narrow, real case

BitPay lets clients settle invoices in Bitcoin, with the payment landing in your BitPay account.

Being honest about this one: for most businesses it is not worth the setup. The case where it is worth it is specific and does exist - you sell to a technical or international client base that already holds crypto, and the alternative for them is an international wire with fees and a three-day wait. If that is not your customer, skip it, and do not add it "just in case". Every payment option on an invoice is one more decision you are asking a customer to make.

Choosing without cluttering the invoice

More options is not better. A checkout with six buttons asks the customer to compare methods instead of paying, and the extra ones are configuration you maintain forever.

Four questions settle it:

Where are your clients? Not where you are. Regional coverage is the only reason most of these modules exist.
Is the revenue recurring? If yes, direct debit is a bigger win than any card optimisation.
What do they already use? The right answer is almost always the method they do not have to think about.
What will you actually reconcile? Every gateway is another account to check against the books at month end.

Start from your five slowest-paying clients and ask what would have made paying easier for each of them. That list is usually shorter than the catalogue, and it is the one worth acting on.

Concord CRM Modules: From Sales CRM to Business System

Themesic Interactive — Fri, 07 Aug 2026 05:30:42 +0000

Concord CRM is good at the thing it set out to do. Deals move through a pipeline, contacts and companies stay tidy, activities get logged, and the whole thing runs on your own server with no per-seat bill. Then a deal closes, and you leave the CRM to do everything that follows.

That gap is the subject of this post. Full disclosure before we go further: we build and sell the modules described here, so treat this as an inventory of what is possible rather than a neutral market survey. The useful part is not the product list - it is the pattern of which gaps are worth closing inside the CRM and which are not.

The shape of the gap

A sales CRM ends at "won". A business does not. The work that follows a closed deal splits into four fairly predictable areas:

Area	The question it answers
Billing	How do we get paid for what we just sold?
Books	What did that revenue actually cost us?
People	Who did the work, and what are we paying them?
Stock	Do we have the thing we sold, and where is it?

Every one of these has an excellent standalone SaaS answer. The reason to do them inside the CRM instead is not features - a dedicated accounting package will always have more. It is that the alternative means a synchronisation problem forever: two systems with two copies of every client, drifting apart in ways nobody notices until an invoice goes to a customer's old address.

Billing: closing the loop on a won deal

The first thing most Concord installs need is invoicing, because the gap is so visible. A deal reaches "won" and the CRM's involvement ends, while somebody opens a separate tool, retypes the client, and raises the invoice by hand.

The invoicing module puts that inside the deal workflow: raise an invoice from the deal, collect payment online, and let the deal advance on its own when the payment lands. The detail that matters is the last one. An invoice that updates the pipeline means the pipeline stays true without anybody maintaining it, and "paid" stops being something a person has to remember to record.

Books: the layer under the invoices

Invoicing tells you what you billed. It does not tell you what you earned. The accounting and bookkeeping module adds the layer underneath: chart of accounts, journal entries, expenses, vendor bills, payments, bank accounts, bank transaction import and reconciliation, budgets, multi-currency, and financial reports.

This is the module to think hardest about before installing, because it has the strongest external competition. The honest test is whether your accountant needs to be in the system. If they do, a dedicated package they already know may win on their comfort alone. If bookkeeping is something you do so that you know where you stand, and your accountant only ever sees exports, then keeping the ledger next to the revenue that generated it is a real simplification.

People: the workforce behind the deals

The HR module covers the workforce lifecycle - onboarding, departments, leave tracking, attendance, timesheet approvals, and payroll with payslip generation.

The argument for putting HR in the CRM is weaker than the argument for billing, and it is worth being clear about why: HR data has almost no overlap with sales data. What it does share is people. If your staff already sign in to Concord every day, adding leave requests and timesheets there means one system, one login, one set of permissions - and for a team under about thirty people that convenience usually beats the feature depth of a separate HR platform.

Stock and procurement: for anyone selling a physical thing

If what you sell has to exist somewhere before you can ship it, two more modules apply. Inventory management handles warehouses, stock levels and work in progress; purchase management handles procurement and supplier billing on the way in.

These are the most conditional items on the list. A services business should skip them entirely. A business selling goods will find the CRM is otherwise lying to it, because a pipeline that does not know what is in stock will happily let somebody sell something that is not there.

The different one: selling Concord itself

The SaaS module is not an extension of your operations - it changes what your business is. It turns a single Concord installation into a multi-tenant platform with automated tenant provisioning, subscription management and usage quotas, so you sell workspaces rather than use one.

That is a different company with different problems: support, uptime, billing disputes and churn all become yours. It is a real path and people do it successfully, but it deserves its own decision rather than a place on a shopping list.

How to decide

The trap is treating this as a menu. Every module you install is code you carry through every Concord upgrade, so the question is never "would this be useful" - almost anything would be. The question is whether the alternative is worse.

Three questions settle most cases:

Is the data already in the CRM? Invoicing wins easily, because the client, the deal and the amount are all there already. HR wins by less, because it shares only the people.
Would the alternative mean syncing? Two systems holding the same customer records will drift. If the answer is yes, the integrated option is usually right even when it is the weaker product.
Who else has to use it? A tool your accountant or your warehouse staff live in every day should be chosen for them, not for you.

Start with the module that closes the loop on work you already do daily. For most Concord installations that is invoicing, and it is worth seeing whether a self-maintaining pipeline changes anything before adding a second.

Perfex CRM Security: Hardening a Self-Hosted Install

Themesic Interactive — Fri, 07 Aug 2026 04:44:24 +0000

Self-hosting a CRM buys you two things a SaaS never will: the data stays on hardware you choose, and nobody can change the pricing, the terms or the feature set out from under you. The bill for that is security. There is no vendor security team quietly patching things at 3am on your behalf. The install is yours, and so is every way into it.

The good news is that the work is finite and mostly one-off. A self-hosted Perfex CRM has a small, well-understood attack surface, and almost all of it can be closed in an afternoon.

What actually gets attacked

Not your custom fields. Not your workflows. In practice, the traffic that finds a self-hosted CRM falls into three buckets:

Automated login attempts. Your admin sign-in page is reachable from anywhere on the internet, and scanners find it within days of the domain resolving. They are not targeting you specifically. They are trying a credential list against every login form they can reach.
Known paths and old software. Bots request predictable URLs looking for a version with a published vulnerability. An unpatched PHP release or a stale third-party library is worth far more to them than guessing a password.
Anything you left readable. A backup .sql in the web root, a .env served as plain text, an open directory listing. These need no exploit at all - just a request.

Everything below is aimed at those three, in that order.

The three layers

Layer	What it protects	Who owns it
Host	The server, PHP, TLS, file permissions	You and your hosting provider
Application	Login, sessions, staff access	Perfex plus whatever you add to it
Data	Backups, database credentials, exports	You

Most write-ups only cover the middle row. The rows above and below it are where the cheap wins are.

Layer 1: the host

Keep PHP current. This is the highest-value item on the list and the one most often skipped, because an old PHP version keeps working right up until it does not. A release that has left security support gets no fixes at all, however carefully the application on top of it is written. Check which version you are on and when it stops being supported, then plan the upgrade before that date rather than after an incident.

Serve everything over TLS, and only TLS. Redirect port 80 to 443, and add HSTS once you are confident nothing legitimate still uses plain HTTP. A CRM login posted over an unencrypted connection is readable by every hop in between.

Turn off directory listing and confirm that files outside the intended document root are not reachable. The quickest test is to request a path you know exists but should never be public, and see what comes back.

Get the file permissions right. The web server needs to write to upload directories and nowhere else. Configuration files should not be world-readable. If one Unix account owns the files, runs the web server and holds the database password, then a bug anywhere becomes a bug everywhere.

Rate limit at the edge if you can. Cloudflare, a reverse proxy or fail2ban will drop a chunk of hostile traffic before PHP is ever started. Work done at the edge costs your server nothing.

Layer 2: the application

This is where a security module earns its place, because the things worth doing here are tedious to build and easy to get subtly wrong.

Throttle failed logins. An attacker with unlimited attempts will eventually succeed against a weak password. An attacker who gets five attempts and then waits fifteen minutes will not. This is the highest-impact application-level control there is, and it is worth tuning rather than accepting a default: how many failures before a lockout, how long the lockout lasts, and how much longer it gets when the same account is locked repeatedly.

Our own PerfShield exists for exactly this. It adds configurable limits for maximum login retries, lockout duration, escalating extended lockouts after repeated offences, password-reset attempt caps, and a ceiling on outgoing security emails so the system cannot be turned into a relay. It runs on Perfex CRM 3.0 or later and needs PHP's allow_url_fopen enabled - a setting most hosts already have on, but one worth confirming. The equivalent for RISE CRM is RiseGuard.

Block the obvious offenders outright. Waiting for repeated failures is reactive. If a range has never had a legitimate user on it and keeps appearing in your logs, denying it up front is cheaper than tolerating it. IP, IP-range and per-user blacklists turn a recurring nuisance into a non-event.

Restrict who can change the security settings. A protective layer that every staff member can switch off is decoration. Access to the security configuration should be its own permission, held by the few people who actually administer the system.

Protect against locking yourself out. Any lockout mechanism needs an answer for the administrator account, otherwise a bad afternoon turns into a support ticket against your own CRM. Check this before you need it, not during.

Layer 3: the data

Back up somewhere the web server cannot reach. A backup sitting in the document root is not a backup, it is a copy of your entire customer database available on request. Push it off the machine, and confirm the destination is not itself publicly listable.

Give the database its own restricted user. The CRM does not need DROP DATABASE. A least-privilege account limits what a successful injection anywhere in the stack can actually do.

Treat exports as live data. A CSV of every client, sitting in someone's downloads folder or on a shared drive, is the same data with none of the protections. Decide who can export, and keep that permission narrow.

Test a restore. An untested backup is a hypothesis. Restore into a scratch environment once and you will find the missing piece - almost everyone does - while it is still cheap to find.

What to do this week

If you only have an hour, do these five, in order:

Check your PHP version and its security-support end date.
Confirm HTTPS is enforced and no plain-HTTP route remains.
Look at your access log and count the failed login attempts from the last seven days. The number is usually a surprise.
Put a limit on those attempts, with an escalating lockout.
Verify your most recent backup is off the machine and actually restores.

None of this is exotic. It is the difference between a CRM that is self-hosted and a CRM that is merely unmanaged.

What Running a White Label CRM SaaS Script Actually Takes

Themesic Interactive — Fri, 07 Aug 2026 04:39:42 +0000

Every agency that resells lead generation eventually hits the same fork in the road: keep paying per-seat fees to someone else's CRM forever, or run the platform yourself and charge your own customers for it. Building a multi-tenant CRM from scratch means writing tenancy, roles, billing, dunning and audit logging before you can send a single invoice. A white label CRM SaaS script compresses that: you buy the codebase, install it on your own server, and sell branded workspaces on plans you define. Full disclosure before we go further: we build and sell LeadHub, the script this post uses as its worked example.

This is a business post, not an architecture tour. The honest framing up front is that a script solves the product problem. It does not solve the hosting, support or marketing problems, and anyone who tells you otherwise is selling a dream rather than software.

What a white label CRM SaaS script covers (and what it does not)

LeadHub is a self-hosted Laravel 13 application with a Filament 4 admin. You get the complete unencrypted source - no IonCube, no obfuscation - which matters more than it sounds: your business should not depend on code you cannot read. A browser-driven installer sets it up without SSH or Composer, and updates run from the browser too, including database migrations. That makes shared hosting a realistic starting point: URL-based cron, an optional sync mail driver for hosts where queue workers cannot run, and a health endpoint that probes DB, cache and storage are in the box.

The multi-tenant part is the point. Each tenant - your paying customer - gets a workspace with its own leads, pipelines, automations, forms, booking calendar and team, isolated at the query level so tenants never see each other's leads, deals or settings. White labeling is per tenant: logo, favicon, primary and accent colors, app name and footer text, so your platform brand never leaks into their dashboard. Access is governed by six roles, from super-admin down to customer.

You operate everything from a super-admin panel: tenant management (create, suspend, activate, restore, refund, hard-delete), a plan builder, coupons, tax rates, gateway credentials, audit logs, database backups, and a dashboard showing total tenants, active subscriptions, MRR, ARR and churn rate. Those are the numbers you will actually stare at as an operator.

Tenant onboarding, from signup to first invoice

A tenant's lifecycle starts with a configurable free trial that expires automatically. From there the built-in email machinery takes over: a Day 0 / Day 2 / Day 5 / Day 10 onboarding sequence, a behavior-based trial drip with localized subjects in four languages, trial-expiry notices, and plan-limit alerts as tenants approach their lead, seat or storage caps. That is retention plumbing you would otherwise have to script yourself in week one.

New tenants also do not start from a blank slate. A built-in marketplace ships pre-built automations, sequences, forms and pipelines that install in one click; you curate the library from the super-admin panel and can feature-gate installs per plan. The 2.0.0 release seeded it with free starter templates: a welcome automation, a contact form, a B2B pipeline and a 3-day onboarding sequence. Tenants invite their own team through signed, single-use expiring links with role pre-assignment.

If you sell to businesses, two compliance details save time in procurement reviews: an Article 28 Data Processing Agreement is a public download, and erasure is a 30-day cool-off workspace deletion with a reachable cancellation banner rather than an instant wipe.

And when a tenant emails you confused, one-click impersonation opens a 60-minute audited session inside their workspace, with no password requests and a full audit trail. For a small operator that is the difference between fixing the problem yourself and a long screenshot thread with a frustrated customer.

Plans, packages and feature gates

Plans carry monthly and annual pricing, with an operator-configurable annual discount per plan, plus usage limits and seat caps. Feature gates control access per plan: lead sources, the AI Lead Coach, marketplace installs, white-label, API access, webhook quota and team seats. Since 2.0.9, plan feature flags can also hide entire admin sections per tier - Reports, Brand and Domain, Communications, Advanced, Tools and Templates - so a starter tier does not even see what it has not paid for.

A coupon system covers percentage and fixed-amount discounts, trial extensions, usage limits, date ranges and plan restrictions, which is enough to run launch promos and win-back offers without touching code.

One packaging detail worth planning around: the AI layer (the Lead Coach, the LeadBot website chatbot and the AI SDR follow-up agent) is optional and plan-gated, and the CRM runs fully without any LLM key. The three features run on the single key you set as platform owner, with built-in daily caps, so AI can be your premium-tier differentiator at a predictable cost rather than a fixed expense in every plan.

Billing: five gateways, receipts and dunning

The billing engine speaks five gateways: Stripe (Hosted Checkout, Customer Portal, recurring subscriptions, webhook idempotency, refunds with credit-note receipts), PayPal (billing-subscriptions API with signed-webhook verification and an out-of-order event guard), Razorpay for the Indian market, Paystack for Sub-Saharan Africa, and manual bank transfer with super-admin confirmation and configurable bank-detail templating.

Receipts are tax-compliant with sequential numbering (LH-YYYY-NNNNNN), EU VAT and US sales tax support, and per-tenant currency; refunds auto-generate negative credit notes for clean year-end accounting. Tenants enter their own business name, VAT or GST id and billing address, so the paperwork is right from the first charge. Failed payments trigger escalating dunning emails that end in suspension. An affiliate engine with referral codes, recurring 20% commission tracking and a payout audit trail lets your earliest happy customers become an acquisition channel.

What you still have to bring yourself

Be clear-eyed about this list, because the script does none of it:

Hosting and operations. Self-hosted means your server, your uptime, your SSL, your backup discipline. The app generates verifiable, downloadable database backups, but storing them off-server and testing restores is on you.
Accounts and keys. Gateways bill into your own Stripe, PayPal, Razorpay or Paystack accounts. Email needs your SMTP provider. Click-to-call and SMS need a Twilio or Plivo account. The AI features need an LLM API key you pay for.
Support. To your tenants, you are the vendor. Impersonation and audit logs make troubleshooting fast, but someone still has to answer the tickets, and the pre-sales questions, and the refund requests.
Marketing. No codebase acquires customers. There is a platform landing-page builder for your own public site, but positioning, pricing strategy, content and ads are your actual job as a SaaS operator. Expect it to take more of your time than the software ever will.

When this is the wrong tool

If you want zero operational responsibility, a hosted CRM subscription is the better deal. You are trading recurring fees for ops work, and that trade only pays off if you have, or intend to build, a paying customer base. If your niche needs deep custom features, full source makes forking possible, but you then own the merge work on every update, and possible is not free. LeadHub is also a young product: version 2.0.9, updated 2026-07-30, with 27 sales on CodeCanyon, which is a real but small install base. We think shipping the entire unencrypted source is the honest counterweight to that risk, because whatever happens, the code runs on your server and stays yours. Finally, if you only ever need a private CRM for one team, self-service registration can be disabled so LeadHub runs as a single internal workspace, but a simpler single-tenant tool may serve you just as well.

Key facts

Fact	Detail
Current version	2.0.9 (updated 2026-07-30)
Server requirements	PHP 8.4+, MySQL 5.7+/8.x or MariaDB 10.3+, SMTP
Payment gateways	Stripe, PayPal, Razorpay, Paystack, manual bank transfer
Lead capture channels	19 native sources
Delivery	Full unencrypted source, free updates
Track record	27 sales on CodeCanyon

Links

If you are weighing the operator side - dunning flows, feature-gate strategy, what tenant support actually costs in hours - ask away in the comments and we will answer from experience.

Perfex CRM SMS Notifications: Playbooks for Invoices, Tasks, Tickets

Themesic Interactive — Thu, 06 Aug 2026 06:00:01 +0000

Perfex CRM is good at storing customer data and quietly bad at making sure customers actually hear from you. Invoices sit unpaid because the reminder never went out, support tickets get resolved and never followed up, and the messages that do leave the building are rewritten from scratch each time, in whatever tone the sender was in that day. This article is about fixing that with Perfex CRM SMS notifications, plus email and WhatsApp, driven by templates, recipient groups, and scheduled delivery instead of somebody's memory.

Full disclosure: we build and sell the module discussed below, Custom SMS & Email Notifications for Perfex CRM. It has 688 sales on CodeCanyon and a 4.40/5 rating from 20 verified CodeCanyon reviews. Everything in this post sticks to what the module documents, and there is a section near the end on when it is the wrong tool for the job.

Why messaging belongs inside the CRM

The usual failure mode looks like this: someone exports contacts to a CSV, uploads it to a third-party blast tool, and within a month the list is stale, the opt-out state lives in two places, and nobody can say which customer got which message. Sending from inside Perfex avoids the split brain. The CRM already knows who your customers and leads are, which of their contacts are active, and which company each contact belongs to, so a message composed there can pull those fields directly and keep your team off blast tools that never see your CRM data.

The second reason is accountability. When a customer says "we never received a reminder," you want a message log with real counts, not a shrug. Communication that lives in the CRM leaves the same audit trail as everything else you do there.

How Perfex CRM SMS notifications work with this module

The module adds one compose screen that covers three channels:

SMS through Clickatell, MSG91, or Twilio
Email, with dynamic subjects and merge fields
WhatsApp through the official Twilio WhatsApp Business API

You pick recipients manually, by selecting a saved recipient group, or by searching the customers and leads list dynamically instead of scrolling it. Every contact attached to the selected customer or lead receives the notification, and an active-contact setting narrows that to only a customer's active contacts. When WhatsApp is enabled, those messages route through Twilio rather than the built-in Perfex SMS gateway, and a dedicated WhatsApp settings page includes a test sender so you can confirm everything works before going live. An optional delivery badges setting surfaces WhatsApp delivery status on your messages.

Two smaller details matter more in practice than they sound. A delivery preview shows exactly how a message will look before it goes out, including the subject label and HTML rendering for email. And a live SMS counter tracks character count and message segments as you type, across both GSM and Unicode encoding. If one stray emoji has ever flipped a campaign to Unicode and multiplied your segment count, you know why that counter exists.

Templates, merge fields, and scheduling

Templates are where consistency comes from. You build a library of email and SMS templates, organize them into categories, and mark each one either private to you or shared with all staff. Merge fields, including {contact_firstname}, {contact_lastname}, and {client_company}, populate both email subjects and message bodies automatically, so "Hi {contact_firstname}" becomes a real per-contact greeting without anyone editing the text.

Scheduling is the automation half. Set a future date and time and the module delivers the message for you. Every scheduled send sits in a dedicated list where you can preview it, edit it, or send it now on demand. Message history logs every message with sent, failed, and scheduled counts and exports to CSV, and send actions, scheduled ones included, are recorded in the Perfex activity log.

Three playbooks you can copy

One framing note first, because it matters: this module's automation primitive is the scheduled send. Each playbook below hangs off a real CRM moment, an invoice going out, a task wrapping up, a ticket closing, but a person creates the send and the scheduler delivers it. That is workflow automation, not an event trigger engine, and the distinction comes up again in the limits section.

1. Invoice reminders

Create a "Billing" template category with a matched pair: an email template with a dynamic subject like "Payment reminder for {client_company}" and a short SMS version for the customers who never open email. When an invoice goes out, schedule the reminder in the same sitting, dated a few days before the due date. If the customer pays early, the scheduled list lets you preview and edit the pending send before it fires. At month end, review the failed count in message history and export the CSV so finance has a record of who was reminded and when.

2. Task and project updates

Set up a shared "Project updates" category so every staff member sends the same wording, and use the module's permissions to restrict sending to the staff who should be messaging clients at all. When a milestone or task wraps up, the assignee searches for the customer from the compose screen, picks the template, and sends. Email attachments are supported, so a report or deliverable can ride along with the update instead of arriving in a separate thread.

3. Ticket follow-ups

Resolution time is when customers judge you, and the day-after follow-up is where most teams go silent. After closing a ticket, schedule a short check-in for the next morning: "Hi {contact_firstname}, we resolved your request yesterday. Reply here if anything still looks off." Active-contact targeting keeps the send limited to the customer's active contacts, and where customers prefer WhatsApp you can send the check-in there and let the delivery badges show its delivery status.

Key facts

Fact	Detail
Current version	2.3.6, updated 2026-05-01
Channels	SMS, email, WhatsApp
SMS gateways	Clickatell, MSG91, Twilio
WhatsApp	Official Twilio WhatsApp Business API only
Compatibility	Latest Perfex CRM, PHP 7.4 or higher; no coding required
Track record	688 sales on CodeCanyon, 4.40/5 from 20 verified CodeCanyon reviews

When this module is the wrong choice

The documentation covers composing, templating, recipient groups, scheduling, and logging. It does not document firing messages automatically the instant a CRM event happens, so if your requirement is "text every customer the moment an invoice is created, with zero human involvement," this is not that product, and we would rather say so here than in a support thread. Recipient groups are static lists you create, not dynamic segments that recompute themselves. Delivery costs sit with your SMS or WhatsApp provider account, not with the module. And the WhatsApp channel specifically requires the official Twilio WhatsApp Business API, so a team without Twilio is limited to SMS and email. If everything you send is a plain transactional email, the stock Perfex email system may already cover you.

Links

If you have questions about a playbook, a gateway, or whether this fits your Perfex setup, ask in the comments and we will answer.

Why your CRM needs an inbox: inside a Perfex CRM email client

Themesic Interactive — Mon, 03 Aug 2026 16:29:01 +0000

Watch a support agent answer one customer email and count the tabs: webmail in one, Perfex CRM in another, and the invoice or ticket they need in a third. Every reply means re-finding the customer record, re-checking the balance, and copy-pasting context between windows. That is the context-switching tax, and busy teams pay it dozens of times a day. A Perfex CRM email client attacks the problem at its root: it puts the inbox inside the CRM, right next to the records the email is actually about.

Full disclosure up front: we are Themesic Interactive, and we build and sell Mailbox, the module this article walks through. It is the number 2 best-seller in our catalog with 1835 sales on CodeCanyon and 4.78/5 from 41 verified CodeCanyon reviews, so read this as a guided tour with the vendor bias declared, not a neutral review.

The context-switching tax, in practice

The tax is not the two seconds a tab switch takes. It is what gets dropped in transit. An email arrives from a client; the agent answers it in webmail and never files it in the CRM, so the next colleague who opens that client's profile sees nothing. A billing question gets a cheerful reply from someone who never noticed the client has an overdue invoice, because the balance was two tabs away.

The common workarounds - BCC-to-CRM addresses, browser extensions - fail the same way: they depend on a human remembering an extra step on every single message. The structural fix is to reverse the direction: instead of pushing individual emails into the CRM, pull the whole inbox in and make the filing automatic.

What a Perfex CRM email client actually changes

Mailbox connects each staff member's own IMAP account to Perfex's admin area. Everyone gets a Gmail-style inbox inside the CRM: threaded conversations with collapsible replies, a split preview pane, archive and snooze, stars and important flags, multi-filter search, bulk actions, and three density settings (Cozy, Comfortable, Compact). Company email is centralized while inboxes stay separate and private - each user signs in with their own profile email address and maps their own Sent, Drafts, Trash, Spam and Archive folders.

The CRM side is where it earns its keep. Open any message and a sender context sidebar shows the whole relationship at a glance: company, open invoices, overdue balance, open tickets and recent conversation history, with a direct link to the customer or lead profile. From the same message you can:

assign it to a customer, so the thread lives on that profile next to invoices, projects and tickets
convert it to a task, with an assignee and a deadline, linked back to the conversation
convert it to a support ticket, tagged, prioritized and routed to the right department
link it to a lead, where a dedicated Conversation tab collects every assigned email into one history
raise an estimate, invoice or proposal in one click, pre-filled for the linked customer or lead

Most of the filing you never do at all. Smart CRM auto-link matches the sender of every incoming message against your records and attaches it to the right customer or lead as it arrives. It is deliberately conservative: only an exact, single, active match is linked; an ambiguous address is left for a human to decide.

Automation: rules, lead capture and follow-ups

The rules engine matches on sender, subject, body or recipient, then acts inside the CRM: link the message to a client or lead, capture a brand-new lead, create a task or a support ticket, assign it to a staff member, snooze it, star it or tag it. Build the workflow once and incoming mail routes itself. Auto lead capture goes a step further: a message from an unknown sender to your sales address becomes a Perfex lead on its own, filed against the original conversation. It is careful about noise - newsletters, no-reply addresses and system notifications are skipped, existing contacts and leads are never duplicated, and a rejected lead is not recreated by the next email.

Two features target dropped conversations. Follow-up reminders let you flag a sent email with a remind-me-if-no-reply timer; if the client answers, the reminder cancels itself, and if they stay silent you get a Perfex notification at the right moment. First-response tracking gives incoming messages Due soon, Overdue or Answered in time badges against a target you set, with automated senders ignored because a newsletter is not a case to answer.

On the compose side there are reusable templates and signature management, saved replies (personal or shared, with merge tags such as {contact_firstname} and {client_company} filled from the email you are answering), a WYSIWYG editor with attachments and inline images, keyboard shortcuts, and Send Later scheduling. Color-coded tags and labels, nested folders and quick-move actions handle triage at volume.

What the sync actually does (developer notes)

Under the hood Mailbox runs on Webklex/php-imap v4.x. By default it performs a one-way sync: unread inbox mail is fetched into Perfex in the background via Perfex's cron, and actions like Star, Trash and Important are stored locally in the database along with attachments. A manual sync endpoint pulls mail on demand. Optionally, per-staff read status sync writes the read state back to your mail server, so opening a message in Perfex marks it read in Gmail or Outlook too.

Each sync mode (unread only versus fetch all) keeps its own checkpoint, so toggling the setting does not skip older messages or re-import already-synced mail. UIDVALIDITY tracking stops mailbox rebuilds and migrations from silently skipping new mail. Message bodies are fetched once per cycle, batch processing covers the initial sync of large inboxes, and database indexes plus full-text search across subject and body (with an automatic fallback on older MySQL versions) keep the list view responsive.

Authentication is OAuth2 for Gmail and Outlook - tokens encrypted and refreshed automatically, Outlook handled through a single Exchange Online resource with SMTP XOAUTH2 sending - and AES-256-CBC encryption where passwords are still used. The module has been through a security audit and hardened on the back of it: staff mail is strictly scoped to its owner across every view and action, email content is sanitized against a strict allowlist, attachments are served through an authenticated download-only endpoint that cannot execute, state-changing actions require POST, and the OAuth flow validates an anti-CSRF state token.

Who benefits, and who does not

The teams that gain the most already live in Perfex all day. Support agents get ticket conversion and first-response badges in the same pane where they read mail. Salespeople get lead linking, auto-captured leads, the Conversation tab, follow-up reminders that cancel themselves, and every linked email written to the lead's native activity feed. Anyone who invoices gets the overdue balance staring at them before they hit reply.

Honest limits: if your team spends its day in Gmail or Outlook and only opens the CRM weekly, moving the inbox into Perfex solves a problem you do not have. The default sync is one-way - beyond the optional read-status write-back, stars and deletions live in Perfex's database, not on your mail server. POP-only accounts are not supported; you need IMAP with SSL/TLS. Only Gmail and Outlook get OAuth2; with any other provider, an account using two-factor authentication needs it disabled before the mail server will accept the connection. A correctly configured Perfex cron is a hard requirement, since fetching happens in the background, and outbound mail goes through Perfex's own outgoing email settings, with sent messages stored in the module's Sent folder.

Key facts

Fact	Detail
Current version	2.3.1 (updated 2026-08-03)
Requires	Perfex CRM, PHP 7.4 or newer, working cron
Mail protocol	IMAP over SSL/TLS (POP not supported)
Authentication	OAuth2 for Gmail and Outlook; AES-256-CBC for stored passwords
Track record	1835 sales on CodeCanyon, 4.78/5 from 41 verified CodeCanyon reviews

Mailbox is a one-time purchase, with a yearly Pro license for teams that want lifetime support.

Links

If you have questions about the sync model, the rules engine, or whether this fits your setup, ask in the comments - we read all of them.

MCP Server for CRM AI Agents: Design Notes From Shipping One in PHP

Themesic Interactive — Mon, 03 Aug 2026 16:22:21 +0000

MCP support went from a niche spec to a standard buyer question faster than most of us expected. If you ship developer-facing software, someone has probably already asked whether Claude, ChatGPT, Cursor or an n8n agent can talk to it, and for most self-hosted products the honest answer is "not safely." We recently shipped a native MCP server for CRM AI agents inside Perfex CRM, a self-hosted PHP application, and this post walks through the design decisions: where the JSON-RPC 2.0 endpoint lives, why we permission-filter 148 tools per API token instead of exposing everything, and why read-only is our default posture. Full disclosure: we build and sell the module discussed here, but the trade-offs apply to anyone embedding MCP in an existing product.

Some context so the constraints make sense. Our REST API module for Perfex CRM (currently v3.1.0) exposed CRM resources - customers, leads, invoices, projects, tasks, tickets - over plain REST for many releases before v3, with per-token permissions deciding what each integration may touch. Version 3 added the MCP layer on top of that existing surface, and that turned out to be the most important architectural fact of the whole project: we did not design an agent interface from scratch, we projected an already permissioned API into the MCP tool model.

Why the MCP server lives inside the PHP app

The path of least resistance would have been a bridge: a small Node or Python process that speaks MCP on one side and calls the REST API on the other. Many MCP servers for existing products are built this way, and for a hosted SaaS with a single deployment it can be a fine answer.

For self-hosted software it falls apart at distribution. Perfex installs run in environments their owners control and we do not - often shared hosting or a small VPS - and asking an administrator to operate a second long-lived process next to a PHP app is a support burden at best and impossible at worst. A bridge also duplicates state: the API token lives in the CRM, a copy lives in the bridge config, and the permission model has to be re-implemented there or, more commonly, skipped.

So the MCP server is native. The endpoint is POST /api/mcp, speaking JSON-RPC 2.0 over Streamable HTTP, and it ships inside the same module as the REST API, enabled by a toggle in the module's platform settings. This matches PHP's execution model surprisingly well: with Streamable HTTP each JSON-RPC message arrives as an ordinary HTTP POST, so there is no resident process to babysit - just the request-per-execution model PHP has always had. Authentication reuses the existing API tokens (sent in the authtoken header, created in the API Management screen under Setup in the admin area), so an agent presents exactly the credential any integration would, and the same middleware evaluates it.

An MCP server for CRM AI agents should not expose everything

The module defines 148 tools. A naive MCP integration would return all of them from tools/list and enforce permissions only when a tool is called. We rejected that, and it is the decision we would defend hardest.

Instead, tools/list is permission-filtered: a tool appears only if the token behind the request holds the matching permission. Grants are per resource and per verb - Get, Create, Update, Delete - so a token limited to reading invoices produces a short tool list that can read invoices and do nothing else. Granting a capability in the permission editor is the same act that makes its tools visible to an agent.

Three reasons drove this. First, context economics: every tool definition you return is prompt space the client model has to carry, and tool-selection accuracy degrades as the list grows. An agent doing invoice lookups gains nothing from the schemas of tools it can never call. Second, security shape: a capability that is never listed cannot be called, planned around or hallucinated into a multi-step workflow; failing at list time is a stronger invariant than failing at call time. Third, honesty in errors: the expose-everything approach produces agents that confidently attempt forbidden operations, burn a round trip, then improvise around a 403. Filtering the list keeps the model's picture of the world consistent with its actual authority.

Read-only agents as the safety default

LLM agents are probabilistic. A wrong search is a wasted call; a wrong delete is an incident. So our recommended starting posture is a read-only token per agent. The permission editor has a one-click Read-only preset for exactly this reason, alongside per-token request limits, quotas and expiry dates.

The upgrade path is deliberate: run the agent read-only until the workflow proves out, then grant Create or Update on the specific resources it needs, one at a time. For write paths, the API supports an Idempotency-Key header on POST, so a retried create replays the stored response instead of duplicating a record - a property that matters more with agents than with humans, because agents retry enthusiastically. There is also an optional staff-level visibility mode that ties a token to a staff member, scoping data exactly the way the admin panel would for that user.

What agents are actually good at against a CRM

The pattern from our own testing is consistent: agents shine at judgment over small result sets and are a poor fit for repetition.

Good agent tasks look like "find this customer, summarize their open tickets and unpaid invoices, and draft the follow-up", cross-resource questions that would otherwise mean four admin screens, and first-draft record creation where a human reviews before anything is sent. The query itself is fuzzy and the value is synthesis.

Repetitive, fully specified work belongs on the deterministic side of the same module. The OpenAPI spec at GET /api/openapi documents 74 paths and 144 operations for coded integrations, with a reference copy in our examples repository; POST /api/batch executes up to 50 operations in one request; 124 webhook events across 22 event groups push changes out, HMAC-signed and delivered asynchronously with retries; and the n8n community node @themesic/n8n-nodes-perfex-crm covers 20+ resources with 130+ operations plus a polling trigger, next to native Zapier and Make polling endpoints. The rule of thumb we give customers: if you can write the steps down exactly, use REST, batch or a workflow tool; if the steps require reading and deciding, use the MCP server.

Where this approach is the wrong tool

An honest limits section, because MCP is having a hype moment. Do not point an agent at bulk data migration or high-volume sync - per-step LLM latency and token cost make it strictly worse than a scripted REST client, which is what the batch endpoint is for. Do not give an unattended agent write access to financial records; keep a human in the loop for anything that emails a customer or touches money. And if your needs are purely Zapier-style automation with no natural-language component, the connectors will serve you better than MCP will. The MCP server is a complement to the API, not a replacement for engineering.

Key facts

Item	Detail
Module version	3.1.0 (updated 2026-08-05)
MCP endpoint	POST /api/mcp, JSON-RPC 2.0, Streamable HTTP
Tools	148, permission-filtered per API token
REST surface	74 paths, 144 operations (OpenAPI at GET /api/openapi)
Webhooks	124 events in 22 groups, HMAC-signed, async retries
Batch	POST /api/batch, up to 50 operations
Track record	2,941 sales on CodeCanyon, rated 4.91/5 from 44 verified CodeCanyon reviews

Links

If you are embedding MCP in your own product and made different calls on tool filtering or write access, we would genuinely like to hear how it went - questions and pushback welcome in the comments.

Perfex CRM n8n Automation: 5 Practical Workflows You Can Build Today

Themesic Interactive — Mon, 03 Aug 2026 16:22:18 +0000

Perfex CRM is good at being a CRM and quiet about everything else. Leads land on your website and someone retypes them into the admin panel. Invoices go out and follow-up depends on somebody's memory. Finance wants a payments spreadsheet every Monday. This is a hands-on guide to Perfex CRM n8n automation: five workflows built with the free @themesic/n8n-nodes-perfex-crm community node, covering lead capture, invoice follow-ups, a scheduled export to Google Sheets, webhook-driven ticket routing, and wiring the node into an n8n AI Agent. Full disclosure: we build and sell the REST API module for Perfex CRM that the node talks to. The node itself is free and open source.

Why n8n rather than a hosted automation service? Because both halves of the stack can live on your own servers. Perfex is self-hosted and n8n can be self-hosted, so customer data never passes through a third-party automation cloud, and there are no per-task fees when a busy workflow fires ten thousand times a month. Perfex does not ship a full REST API of its own, so the module supplies one: version 3.1.0 documents 74 paths and 144 operations in an OpenAPI 3.0 spec served at GET /api/openapi, with a reference copy in our examples repo.

Setup: the module, a token, and the community node

Three steps before the fun part.

Install and activate the REST API module in Perfex. Activation takes seconds and there is no core patching.
Create an API token under Setup, then API, then API Management. Permissions are granular per resource (Get, Create, Update, Delete), so give each workflow's token only what it needs. A lead-capture token has no business holding Delete on invoices.
In n8n, open Settings, then Community Nodes, and install @themesic/n8n-nodes-perfex-crm. Add a credential with your Perfex URL and the token; the node authenticates every request with the authtoken header.

The node covers 20+ resources with 130+ operations plus a polling trigger, which is enough for everything below.

Five Perfex CRM n8n automation workflows

1. Website lead capture

The classic first workflow. An n8n Webhook node receives the POST from your website form, a Set node maps the form fields to lead fields, and the Perfex node creates the lead. Every create response from the API includes a record_id, so you can chain a step that notifies your team with a link to the new lead, or sets source and assignment in the same run. Once this works, the retyping stops for good.

2. New-invoice follow-up

Use the node's polling trigger to watch for new invoices. When one appears, log it, wait the number of days your follow-up policy says, then re-fetch the invoice and check whether it has been paid. If not, send the reminder. The module exposes invoice emailing over the API (POST /api/invoices/{id}/send), so the reminder can come from Perfex itself, or you can send it from n8n's own email nodes. One detail worth knowing: invoice totals are computed server-side from line items, taxes and discounts, so use the amounts the API returns rather than recalculating them in the workflow.

3. Scheduled payments export to Google Sheets

A Schedule trigger fires Monday at 07:00, the Payments resource lists last week's payments using the API's date-range filters (created_after and created_before), and a Google Sheets node appends the rows. Every list endpoint in the API shares a unified toolkit - pagination, sorting, field selection and date-range filtering - so you can pull only the columns the sheet needs instead of full records. Finance gets the same spreadsheet every week and nobody exports anything by hand.

4. Support ticket routing via webhooks

Polling is fine for invoices; tickets deserve push. The module's Webhooks 2.0 catalog covers 124 events across 22 event groups. Create a webhook pointing at an n8n Webhook node URL and subscribe to the ticket events. In the workflow, verify the HMAC signature first - deliveries are signed with a timestamp in the X-Perfex-Signature header for verification and replay protection - and only then trust the payload. A Switch node does the routing: billing keywords assign the ticket to the billing department, urgent phrasing bumps the priority, everything else takes the default lane, each branch calling the node's ticket update operation. Delivery is asynchronous with automatic retries, so a short n8n restart does not silently drop events.

5. The node as a tool for the n8n AI Agent

n8n can hand nodes to its AI Agent as tools, and the Perfex node is no exception. Attach it with a read-mostly token and the agent can answer questions like "which invoices went out last week" or "summarize the open tickets" against live CRM data. Two guardrails we recommend: give the agent its own dedicated token so its permissions are auditable in one place, and start read-only, adding write operations one at a time as trust builds. If you want to go deeper, the module also ships a native MCP server at POST /api/mcp (JSON-RPC 2.0) exposing 148 permission-filtered tools - a second route into the same CRM for AI agents, with the tool list filtered by the same token permissions.

Key facts

Fact	Value
Module version	3.1.0, updated 2026-08-05
Documented API surface	74 paths, 144 operations (OpenAPI 3.0 at GET /api/openapi)
n8n community node	20+ resources, 130+ operations, plus a polling trigger
Webhooks	124 events in 22 groups, HMAC-signed, async with retries
MCP server	POST /api/mcp, JSON-RPC 2.0, 148 permission-filtered tools
Batch endpoint	POST /api/batch, up to 50 operations per request
Track record	4.91/5 from 44 verified CodeCanyon reviews, 2,941 sales on CodeCanyon

When this is not the right tool

If all you need is a single one-way push - a nightly script that inserts leads from a CSV, say - a short script against the API directly is simpler than operating an n8n instance, and the examples repo, which also carries a reference copy of the OpenAPI spec, is the place to start for direct calls. The module assumes you are comfortable with REST basics; if tokens and JSON payloads are unfamiliar territory, budget for setup help. Operationally: asynchronous webhook delivery works best with a cron job on the Perfex host (there is an admin-load fallback, but a queue that only drains when someone opens the admin panel is not what you want under ticket routing), batch calls cap at 50 operations per request, and self-hosting n8n means updates and backups are your job, not a vendor's. The module is a paid one-time purchase; the n8n node is free but does nothing without it.

Links

If you build one of these workflows, or get stuck halfway through one, tell us in the comments - we read and answer them.

Automating Perfex CRM with a REST API: webhooks, OpenAPI and MCP for AI agents

Themesic Interactive — Mon, 03 Aug 2026 12:51:25 +0000

Full disclosure up front: we build the module discussed here. This is Themesic Interactive's own writeup of the REST API module for Perfex CRM. Every number below is verifiable - the OpenAPI spec, the Postman collection and copy-paste examples all live in a public GitHub repo linked at the end, and you can regenerate the spec from any installation yourself.

The gap

Perfex CRM is a popular self-hosted PHP CRM. Out of the box it has no REST API: no endpoint to create a lead from your website form, no way for n8n or Zapier to react to a new invoice, nothing an AI agent can call.

The REST API for Perfex CRM module adds that layer: 74 paths and 144 operations, with every request body documenting its fields, types and required flags over the CRM's entities (customers, contacts, leads, invoices, estimates, proposals, credit notes, payments, projects, tasks, milestones, tickets, contracts, expenses, items, staff, subscriptions, timesheets, calendar, knowledge base, notes), plus webhooks, a batch endpoint and an MCP server. On CodeCanyon it is rated 4.91/5 from 44 verified reviews across 2,941 sales, and v3.1.0 is the release this article uses.

60 seconds to your first request

Install the module, then create a token under Setup > API > API Management in the Perfex admin. Every request authenticates with the authtoken header:

curl -H "authtoken: YOUR_API_TOKEN" \
  "https://your-perfex-url/api/customers?page=1&per_page=25"

Creating a lead from anywhere (a landing page handler, a cron job, a chatbot):

curl -X POST "https://your-perfex-url/api/leads" \
  -H "authtoken: YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "Jane Doe", "source": "2", "status": "1", "email": "jane@example.com"}'

List endpoints take opt-in modifiers, so you only pull what you need:

GET /api/invoices?fields=id,total,status&sort=-date
GET /api/customers?created_after=2026-01-01&created_before=2026-06-30
GET /api/leads/search/acme

Writes support an Idempotency-Key header for safe retries, and responses carry X-RateLimit-* headers so your integration can back off politely.

Webhooks instead of polling

Since v3.0 the module ships 124 webhook events across 22 event groups, managed entirely over REST:

POST /api/webhooks              # subscribe a URL to events
GET  /api/webhooks/events       # list all 124 available events
POST /api/webhooks/{id}/toggle  # pause and resume
GET  /api/webhooks/{id}/logs    # delivery history for debugging

Deliveries are asynchronous with retries, requests are HMAC-signed so your receiver can authenticate the payload, and outbound URLs go through SSRF protection. For polling-based tools (Zapier, Make, n8n's trigger nodes) there are ready-made polling endpoints as well, and a POST /api/batch endpoint runs up to 50 operations in one request.

The whole API as one file: OpenAPI

The module describes its entire surface as an OpenAPI 3.0 document, generated live by the installation itself so it always matches the installed version:

curl -H "authtoken: YOUR_API_TOKEN" \
  https://your-perfex-url/api/openapi -o perfex-rest-api.openapi.json

Import that file into Postman, Insomnia or Stoplight and every endpoint, parameter and response shape appears ready to call. Feed it to openapi-generator for typed clients in PHP, Python or TypeScript. A reference copy exported from v3.1.0 is committed in the examples repo if you want to inspect it before installing anything.

MCP: letting AI agents work the CRM

The part we get the most questions about. v3.0 added a native Model Context Protocol (MCP) server at POST /api/mcp (JSON-RPC 2.0). It exposes 148 CRM tools - create invoice, update lead, search customers, log a payment - to Claude Desktop, Cursor, n8n AI Agent nodes and any other MCP client.

The important design decision: tools are permission-filtered. The MCP server only exposes the operations the API token is allowed to perform, so an agent connected with a read-only token physically cannot write to the CRM. Setup for specific clients is documented in the repo's MCP guide.

If you use n8n, there is also a dedicated community node package: n8n-nodes-perfex-crm.

The numbers, in one place

What	Figure
REST surface	74 paths, 144 operations (OpenAPI 3.0)
Webhooks	124 events, HMAC-signed, async with retries
MCP tools for AI agents	148, permission-filtered
Batch	up to 50 operations per request
Automation	native n8n, Zapier, Make polling endpoints
Track record	4.91/5 from 44 verified CodeCanyon reviews, 2,941 sales