Creating a custom object in HubSpot takes about four minutes. Connecting one to anything outside HubSpot is where the quarter goes.
That gap is the whole subject of this guide, and it is not the one most custom object articles cover. There are plenty of good explanations of what a custom object is and how to click through the builder. There are very few that tell you, before you commit your data model to one, that HubSpot's own native sync will carry a custom object to exactly six applications, that it will drop every association even on those six, and that the internal name you type into a box in the first minute can never be changed.
We build and maintain custom HubSpot integrations for a living, so custom objects are most of what we are hired to move. This is what we wish clients knew before the object existed rather than after.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
What a HubSpot Custom Object Is
HubSpot ships with standard objects: contacts, companies, deals, tickets, and a growing set of others. They model what every business has. A custom object models the thing that makes yours specific.
HubSpot's own product catalogue describes the purpose as storing almost any type of data in HubSpot, including subscriptions, locations, shipments, events and more. In practice the objects we see most often are subscriptions, properties in the real-estate sense, policies, shipments, vehicles, courses, projects and licences.
A custom object is a full participant in the CRM rather than a bolt-on. It gets its own properties, its own records, its own associations to standard and custom objects, and its own use in workflows and reporting. That is what separates it from the alternative most teams try first, which is stacking properties onto a contact until the contact record becomes a spreadsheet.
Custom object or custom property?
Two tests settle nearly every case.
Does the thing have its own lifecycle? A renewal date is a property of a deal. A subscription that starts, upgrades, suspends, resumes and renews has a history and a status of its own, and that makes it an object.
Can one record have many of them, and do you need each one separately? If a contact can hold several of the thing and you need to report on them individually, it is an object. The diagnostic symptom is field names ending in numbers. If your contact record has policy_1, policy_2 and policy_3, you have found an object wearing three properties as a disguise, and the reporting problems have probably already started.
What Custom Objects Cost
This is the first gate and it stops a lot of projects.
Two things about that list are worth reading carefully.
It is an account-level entitlement, not a per-seat one. One Enterprise subscription on one hub unlocks custom objects for the portal. You do not need every user on Enterprise.
And Data Hub Starter does not count, which is the assumption we correct most often. Data Hub is the product that carries data sync and custom field mappings, so it feels like the data modelling tier. Custom objects sit above it, at Enterprise, on whichever hub you choose to buy it on.
If you are not on Enterprise anywhere, the honest answer is usually to model the thing with properties or with a standard object you are not otherwise using, and revisit when an Enterprise upgrade is justified on its own merits. Buying Enterprise purely to unlock custom objects is a large annual commitment to solve a data modelling problem, and there is often a less expensive shape for the same information.
How to Create a Custom Object in HubSpot
Two routes, producing the same result.
In the interface, through the data model builder
Go to Data Management, then Data Model, then Create a custom object. The builder walks you through naming the object, defining its properties and setting up its associations to other objects. This is the right route for a one-off object in a single portal, and it is the one most teams use.
Through the custom objects API
HubSpot exposes a schemas API for defining objects programmatically. Take this route when the object has to be created identically across several portals, when it is part of a repeatable setup you will run again, or when the definition should live in version control alongside the integration that populates it. Note that the object API's batch endpoints are limited to 100 inputs per request, which shapes how you backfill records afterwards.
Whichever route you take, slow down at the naming step, because of the next section.
The Two Decisions You Cannot Undo
Almost everything in HubSpot is editable later. These two are not, and both are made in the first few minutes.
The second is deletion. HubSpot documents that you cannot delete a custom object that is currently being used by other tools, and that you will need to remove references to the object from those tools prior to deleting it.
That sounds procedural and it is not. On an object that has been live for a year, the references are spread across workflows, lists, reports, dashboards, forms, sequences and every integration that touches it. Removing them is a project with its own scope, and it has to be finished before the delete button becomes available at all. Custom objects are far easier to create than to retire, and a portal accumulating half-used objects is a common and genuinely expensive form of debt. Our HubSpot audit guide covers how to find what is actually referencing what.
How Many Custom Objects Can You Have?
Here is a small oddity worth knowing, because it affects how confidently you can plan.
HubSpot's knowledge base says that depending on your subscription there are limits on the number of custom objects and properties you may have, and refers you to the HubSpot Products and Services catalog for your limits. The catalog describes the feature, and notes that limits for it vary by product, without publishing the figures.
Ten custom objects per account is the number that circulates in third-party guides, and it may well be correct for your tier. It is simply not a number HubSpot states in the document its own documentation points you to, so treat it as folklore rather than fact until you have checked.
What Actually Connects to a Custom Object
This is the section the rest of the guide exists for, and it is where custom object projects most often go wrong. Not at creation. Two months later, when someone asks why the subscription records are not in the warehouse.
Read that against the way the App Marketplace is usually presented and the shape of the problem is clear. The marketplace is enormous. The subset of it that data sync covers is much smaller. The subset of that which will look at a custom object is six.
So the moment you model your differentiating data as a custom object, you have quietly stepped outside the native integration ecosystem for almost every destination you might want. That is not a bug and it is not badly documented. It is just very easy to not find out until you need it.
And being one of the six buys less than it looks like.
There is one more gate on top. Custom object sync through data sync requires an Enterprise subscription, the same as the objects themselves, so a Data Hub Starter subscription that activates a sync will not activate a custom object sync. The Operations Hub guide covers where the data sync engine stops more generally.
The no-code exception
One genuinely useful thing, and it surprises people who have just read the section above.
Automation platforms will talk to custom objects. Zapier's HubSpot integration includes custom object triggers and actions alongside search, find or create and association actions. So a tool costing $20 a month will move custom object records to a destination that HubSpot's own first-party data sync will not.
That makes an automation platform a reasonable first move when your system is not one of the six, and for plenty of jobs it is the right permanent answer. The caveat is the same as it always is: you are building and operating the integration yourself, in a tool whose safety net is a retry, and a retry does not undo the half of a run that already succeeded. Zapier vs Make compares the two main options on how they meter that work, and note while you are there that custom object records fan out, which is exactly the shape that costs more on per-record billing.
Association Limits Worth Knowing
Associations are how a custom object earns its place, so the limits on them matter more than they do elsewhere.
HubSpot lets you set limits on record associations, available on Professional and Enterprise across Marketing, Sales, Service, Data, Content and Revenue Hub. You can configure any number up to 10,000. There is also a precedence rule worth remembering when you combine the two kinds of limit: if the total association limit is set to one and the label limit is set to custom or many, the association limit takes precedence.
The practical advice is to set these deliberately at design time rather than discovering them. An association limit is a business rule expressed in a settings page, and like every business rule in an integration, the question it answers is which system is allowed to create the relationship. Our data mapping guide covers why that question decides more integration outcomes than any technical constraint.
When Your System Is Not One of the Six
Which is the common case. Four options, in the order most teams should consider them.
Getting custom object data in and out
Check whether it needs to move at all. The cheapest integration is the one you never build. If the custom object exists so people can see it on a contact record, and no other system needs it, you are finished. A surprising number of custom object sync projects are solving a reporting problem that a HubSpot report already solves.
Use an automation platform for low-stakes movement. Zapier and Make both handle custom objects. If the consequence of a missed or duplicated record is that someone reruns something, this is the correct tool and a build would be a waste of money.
Route through one of the six if the shape allows it. Snowflake in particular is worth considering when the destination is analytical rather than operational, since getting custom object records into the warehouse solves reporting without needing associations to survive.
Build against the API when the data is load bearing. Custom objects are, almost by definition, the records that encode what your business actually does, which means they tend to feed invoicing, entitlement, renewals and revenue reporting. Once a wrong record costs more than the integration, you want declared field ownership, associations rebuilt deliberately rather than dropped, and a reconciliation pass that catches drift. Our guide to a custom HubSpot integration covers what that build contains.
Not sure whether your custom object needs a build or a Zap?
Send us what the object models and where it has to reach. We will tell you whether one of the six native connectors covers it, whether an automation platform is genuinely good enough, or whether it is the kind of record that needs building properly. Most answers come back as leave it alone or use Zapier, and that is a useful thing to have in writing.
The Bottom Line
Custom objects are the right tool for the data that makes your business specific, and modelling that data properly is almost always better than stacking numbered properties onto a contact record until reporting stops working.
Go in knowing three things. It is an Enterprise feature on whichever hub you buy it on, with no Professional path. The internal name you type at creation is permanent, and the object cannot be deleted while anything still references it. And native sync will carry custom objects to six applications, dropping associations even on those, which means the moment your differentiating data becomes a custom object, connecting it to anything else stops being a configuration task.
None of that is a reason to avoid custom objects. It is a reason to decide the naming convention, the association rules and the integration path before you create one, because two of those three decisions are much harder to change afterwards than they look on the day.
