The free HubSpot WordPress plugin connects your site to HubSpot contacts. Its feature list does not mention membership data. To connect a membership site to HubSpot, decide which system owns each field. The system that grants access, WordPress, should own plan, status, and join and expiration dates, and push them to HubSpot one way. HubSpot can own marketing fields such as lifecycle stage. Companies and subscriptions need their own mapping, and custom objects need an Enterprise subscription.
We maintain WordPress platforms for established membership businesses and associations, including a HubSpot sync across several record types for a national trade association. We are also a listed WP Fusion Expert, and we describe that plugin route below from its own documentation.
What the HubSpot plugin covers and what it does not list
The official plugin is a general HubSpot connector, and its published feature list does not describe a member-record sync. It is free and shows 200,000+ active installs on WordPress.org (as of October 2026). HubSpot's install guide describes a contacts database where you can associate contact records with companies, deals and more. No plan, expiration date or payment appears in that feature list. That is our reading of the list, not a statement from HubSpot.
For a lead, a form that creates a contact record is the right result. A member on a plan that expires in March needs a lot more than a contact record. Somebody in sales or support will eventually ask which plan they are on, whether they renewed, and which company they belong to. If the answer is not in HubSpot, or is there but wrong, the integration has failed no matter how many contacts it created.
If you already have a sync and the data is drifting, Book a chat and we will look at where the fields collide.
Pick a source of truth for each field
Choose one system to own each field and write the choice down before anyone builds anything. “HubSpot is the source of truth” or “WordPress is the source of truth” is too blunt. The system that grants access should own the fields that control access. Marketing and sales fields can live in HubSpot.
This is the split we use as a starting point:
| Field | Owner | Direction | Reason |
|---|---|---|---|
| Membership plan or level | WordPress | WordPress to HubSpot | Your membership plugin decides what the member can access |
| Status (active, expired, canceled) | WordPress | WordPress to HubSpot | Access follows status, so status cannot be editable somewhere else |
| Join date and expiration date | WordPress | WordPress to HubSpot | A changed expiration date in a CRM can lock out a paying member or extend a lapsed one |
| Payment status as it affects access (paid, past due, lapsed) | WordPress, because it makes the access decision | WordPress to HubSpot | Your payment gateway holds the charge record. The access decision is what you push |
| Company a member belongs to | Decide per organization | Usually WordPress to HubSpot | If membership is sold to companies, WordPress owns it. If it is only a sales label, HubSpot can |
| Email consent and unsubscribes | HubSpot | Stays in HubSpot | Our starting point is to keep consent in HubSpot and stop the sync from overwriting it |
| Lifecycle stage, lead score, sales owner, notes | HubSpot | Stays in HubSpot | Sales and marketing edit these, and WordPress usually does not need them |
| Email engagement | HubSpot | Stays in HubSpot | Leave it where it is recorded |
Two rules go with the table.
- Create new HubSpot properties for membership data. Do not repurpose old ones. A property that already holds years of marketing history is the wrong place to start writing an expiration date.
- Tell staff that the fields WordPress owns are not to be edited in HubSpot, and lock them where your HubSpot setup allows it. If people can edit a field that a sync overwrites, they will, and then the numbers disagree.
Be most careful with expiration dates. If someone fixes a date in HubSpot and nothing carries it back, WordPress keeps granting access on the old date and the two systems disagree. If something does carry it back, one typo in a CRM changes who can log in. Either way, one place should be editable, and for access it should be WordPress.
Why membership data should travel one way
Send membership data from WordPress to HubSpot and nowhere else. A two-way sync needs a rule for every field about who wins when both sides change, and a way to stop updates bouncing between the systems. That is extra machinery for fields that control access, where one-way sync already does the job.
Take a plan change. If the plan can be edited in both places, a staffer fixing a record in HubSpot can change what a member can open on the site, and nobody sees it happen. If only WordPress can change it, HubSpot has one authoritative source for that field, so a report built on it is not caught between two sets of edits.
A request for full two-way sync may really mean that people want HubSpot to show the right data so they can act on it: build a list of members who have not renewed, trigger an email, assign a call. One-way sync, with HubSpot as the reporting and automation hub, can support all of that.
Companies are a different problem from contacts
A company is its own record in HubSpot, separate from the contacts who work there, so a membership sync has to create and associate companies on purpose. A plugin that only writes contacts will not do it for you.
WP Fusion's HubSpot documentation includes a code example for syncing a company. It says the example is very simple and would need additional logic for a new user joining an existing company and for a user changing company. Company syncs tend to break in these places:
- A new member joins a company that already exists in HubSpot.
- A member changes jobs and should move to another company.
- One company has several email domains, so matching on the domain creates duplicates.
- One domain pays for people who use other domains, so the person on the invoice and the person logging in do not match.
Plan for all of these if you sell memberships to organizations. Decide how a company is identified (an ID from WordPress is safer than a domain), what happens when a member moves, and who can merge duplicates in HubSpot, before you write the sync.
Subscriptions and custom objects depend on your HubSpot tier
HubSpot's knowledge base lists subscriptions among its standard objects, next to contacts, deals, payments and conversations. Custom objects are different: the same knowledge base says “An Enterprise subscription is required to use custom objects” (HubSpot, updated October 7, 2026). We could not confirm from the pages we read which HubSpot tiers include the subscriptions object, so check your own plan before you design around it.
Our view on when each shape fits:
- Contact properties (plan, status, join date, expiration date) work when each person has one membership at a time.
- Subscriptions or a custom object make sense when a person or company can hold several memberships or has a history you want to report on.
- Companies come in when the organization is the customer, not just a label.
If a custom object means upgrading to Enterprise, the question for the owner is whether the reporting it enables is worth that line item. Often the answer is to start with properties and add the heavier model later.
Which tool fits which job
Here is our view of which tool fits which job, based on how many record types you need to move.
| Option | What it covers | Where it stops | Fits when |
|---|---|---|---|
| Official HubSpot plugin | Contacts, associated with companies and deals in HubSpot | Membership data is not in its feature list | You need contacts from your WordPress site in HubSpot |
| Zapier | Pushing a new or changed member into a contact | Gets awkward with companies, history and large backfills (our view) | You only need basic contact updates, see our Zapier how-to for pushing members to HubSpot |
| WP Fusion | Contacts, tags (lists in HubSpot) and custom fields, out of the box. Companies and custom objects are possible through its object functions plus custom code | Companies need extra logic, per its own documentation. Custom objects need the HubSpot tier above | The data is mostly contact-shaped. We are a listed WP Fusion Expert, see our WP Fusion review |
| Custom sync | Contacts, companies, subscriptions and rules specific to your membership | You own and maintain the code | Several record types matter, or your rules do not fit a plugin |
Custom sync is the one that needs scoping. If you go that way, custom WordPress plugin development with logging, retries and a clear owner helps keep the sync from becoming a black box that only one person understands.
What we see on real sites
Most sync setups we see push only the user record. The harder version, and the one we have built, moves several record types.
A national trade association whose platform we rebuilt runs a main WordPress site, a separate community site, and HubSpot. User data flows from the main site to the community site, and membership data flows from the main site to HubSpot. We built the HubSpot side one-way, from WordPress to HubSpot, so an edit made in HubSpot cannot change WordPress data, and we explained why.
The sync covers contacts, companies and subscriptions. HubSpot is the reporting hub: anyone on the team can run a report on who failed to renew without opening WordPress.
Companies were the hard part. Some had several email domains, and in some cases one domain paid for people who used another. Those cases turned up after the main sync was running, which is why we now plan for them at the start.
The client's HubSpot partner validated the result. That partner knows how the CRM is used day to day, and we know the membership data. We recommend scoping a sync like this as its own project, not one task card on a retainer.
Plan the backfill before you press go
A first sync of an existing member base is a bulk job, and HubSpot's API limits decide how long it takes. HubSpot's usage guidelines list these limits for private apps (as of October 2026):
| HubSpot plan | Requests per 10 seconds, per app | Requests per day, per account |
|---|---|---|
| Free and Starter | 100 | 250,000 |
| Professional | 190 | 625,000 |
| Enterprise | 190 | 1,000,000 |
Marketplace apps installed through OAuth are limited to 110 requests every 10 seconds per installing account. That limit excludes the CRM Search API.
Here is a best-case example, using our arithmetic and not HubSpot's. It assumes one request per record, sustained maximum throughput and no retries. Moving 100,000 member records takes about 88 minutes at 190 requests per 10 seconds, and about 2.8 hours at 100. If each member needs three calls (contact, company, association), that is 300,000 calls, which is over the 250,000 daily cap on Free and Starter and spills into a second day. HubSpot's object APIs also have batch endpoints that take up to 100 records per request (HubSpot developer docs, as of October 2026), which can cut the request count. Run the backfill off-peak and test it on a copy of the data first.
Apply the same ownership rule to Salesforce
We recommend the same rule for Salesforce: one owner per field, and one-way for anything that controls access. We have built this for HubSpot, not Salesforce, so we have no Salesforce project to point to.
On tooling, WP Fusion's Salesforce page says it syncs to Salesforce fields, including custom fields, and its documentation says custom objects work with Salesforce through the wpf_crm_object_type filter and add_object(). The “Object Sync for Salesforce” plugin on WordPress.org was closed on July 28, 2026 for a security issue and is no longer downloadable. If you find it recommended in an older guide, do not install it.
Frequently asked questions
Can the free HubSpot plugin sync my membership data?
Its published feature list covers HubSpot contacts and does not mention membership data, so we would not rely on it for that. Options for plans and expiration dates include WP Fusion, Zapier and custom code.
Do I need HubSpot Enterprise?
If your design uses custom objects, yes: HubSpot's knowledge base says an Enterprise subscription is required for them. Contacts and companies are standard objects, and a simpler design can use properties instead of a custom object.
Does WP Fusion sync HubSpot companies?
Out of the box it covers contacts, tags (lists in HubSpot) and fields. Its documentation shows how to work with companies and custom objects through its developer functions and custom code, and says company changes need extra logic.
Should HubSpot or WordPress be the source of truth?
Neither wins across the board. The system that grants access, WordPress, should own membership and access fields and push them out. HubSpot can own marketing fields. Pick per field and write it down.
Ready to scope your sync?
If you run a live membership site and want a straight view on which fields belong where and what the build involves, Book a chat and we will talk it through.
Reviewed by Vic Dorfman, founder of MemberFix. We build and maintain WordPress membership platforms and their CRM syncs for a living. Last reviewed: October 2026.
