What You Can and Cannot Build With the HubSpot API

"HubSpot has an API" is true and almost useless as a planning statement. The question that decides whether a project is a two-day automation or a three-week manual rebuild is narrower: can this specific thing be created over the public API?

We keep an internal list because the question comes up on nearly every integration scope. Of roughly two dozen things clients regularly ask to have built or migrated, about half are completable end to end over the public API. The rest need a human in the interface, and the single largest item in that second group is reporting.

What is creatable over the public API

The dependable list, the things we will quote as automated work without hedging:

• CRM records: contacts, companies, deals, tickets and custom objects
• CRM schema: properties, property groups, custom object definitions
• Pipelines and their stages
• Lists
• Workflows
• Forms
• Marketing emails
• HubDB tables and rows
• Behavioural events
• Engagements: calls, notes, tasks, meetings, emails
• Products and line items
• Content: blog posts, web pages, landing pages

That last one is really one capability wearing three names, which is why our honest count of distinct automatable capabilities is closer to nine than twelve.

If a project consists of moving records, defining schema, building lists and workflows, and publishing content, it is automatable and you can quote it with confidence.

What is not

Reports and dashboards. There is no public endpoint that creates them. HubSpot publishes a reporting API reference covering analytics data, and a beta feature that lets a public app receive shared reports, but neither of those builds a report in a portal.

The distinction matters commercially: reading data out and creating an asset inside HubSpot are different problems, and only the first is solved.

The consequences run further than people expect:

No migration tool moves reports. Not because the vendors are lazy, but because every tool is built on the same public API and hits the same ceiling. When a marketplace listing claims report support, treat it as a claim about something narrower. On one portal-to-portal migration we scoped, the manual rebuild left behind was 400+ reports, 120 web pages and 60 landing pages, and the reports were the bulk of the hours.

Dashboards cannot be templated across client portals. An agency that wants a standard reporting pack for every client is going to build it by hand every time. That is worth knowing before you sell a productised reporting offering.

Report logic cannot be audited programmatically. You can enumerate a portal's records, properties and workflows over the API and find the broken ones. Reports have to be opened and read by a person, which is why reporting is the least-audited layer in almost every portal we inherit.

How this changes a quote

Three practical consequences.

Split the quote at the API boundary. Data migration, schema, lists, workflows and content in one section, priced as automated work. Reports and dashboards in another, priced as manual hours per report. Presenting them as one number invites the client to assume the whole thing scales the same way, and it does not.

Count the reports that are still used, not the reports that exist. This is the same discipline as workflow rebuilds. Portals accumulate reports the way they accumulate everything else: on one audit we found 1,306 reports, most of them stale; on another, 222 of 282 were owned by three former agencies' email addresses. Rebuilding all of them would be indefensible. Agreeing the surviving list is the first deliverable, and it usually shrinks the project by more than any technical decision.

Say the constraint out loud, early. "Reports cannot be moved by any tool, so we will rebuild the ones you still use and here is what that costs" is a fine sentence in week one. In week six it sounds like an excuse.

The other constraints that decide feasibility

"Is there an endpoint" is the first question and not the only one. Four more that turn a plausible automation into an unquotable one, in the order they tend to bite.

Rate limits against real volume. An integration that works beautifully against a test portal of 500 records can be structurally impossible at 80,000. The arithmetic is worth doing before the quote: records divided by batch size, multiplied by the per-call latency, tells you whether the job runs in ten minutes or nine hours, and a nine-hour job needs checkpointing, resumability and a failure story that a ten-minute job does not.

Write semantics. HubSpot imports and many endpoints create or update; they do not append. Any design that assumes accumulating values into a field is wrong before it is written. This is the single most common false assumption we correct on inherited integration specs.

What you can read back. Plenty of things can be created and then not retrieved in a shape useful for reconciliation. If you cannot query the result, you cannot prove the job worked, and an integration you cannot verify is an integration you will be arguing about later.

Permission and seat gating. An API token inherits scopes, and some surfaces are gated by the seat model rather than by scopes at all. A call that works in your sandbox under a super admin can fail on the client's portal under the credential they actually issued you.

The practical version: prototype the riskiest single call before the quote goes out. Not the whole integration, one call. Fifteen minutes against the client's real portal tells you more than an afternoon of reading documentation, because it exercises their permissions, their data volume and their field configuration at once.

What "we will automate it" should mean in a proposal

Because this is ultimately a commercial document problem, not a technical one.

An assumptions block that says "HubSpot provides an API for this functionality" is doing no work. It is true of almost everything and it protects nobody. When the thing turns out to be manual, that sentence is what the argument will be about.

What we put in instead, on integration scopes:

• The specific objects and operations, named. "Create and update deal records with company associations," not "sync deals."
• The things explicitly excluded and why, with reports and dashboards named directly when they are in the neighbourhood.
• The volume the estimate assumes, because the estimate is only valid at that volume.
• What the client has to supply, usually a credential with named scopes, and by when.
• How completion is proven. A record count, a reconciliation report, something checkable.

That last one is the difference between a project that ends and one that lingers. If nobody agreed in advance what "done" looks like for a data integration, done is whenever the client stops finding things.

The wider habit: check the surface before you promise

The failure mode this article is really about is not reporting specifically. It is quoting an automation on the assumption that a documented API implies a specific capability.

Before promising anything automated:

1. Name the exact object and the exact operation. Not "we will sync their data" but "we will create deal records with associations to companies."
2. Find the endpoint. If you cannot find it in ten minutes, assume it does not exist rather than that you missed it.
3. Check what the endpoint returns as well as what it accepts. Plenty of things can be created but not read back in a useful shape, which matters for reconciliation.
4. Check the rate limits against your volume. An operation that works for 500 records and dies at 80,000 is a different project.
5. Prototype the riskiest call first, before the quote goes out, not after.

Fifteen minutes of this ahead of a quote is the difference between a project that lands and one that needs a difficult conversation in week three.

What to do when the thing you need is not automatable

Three routes, in the order we consider them.

Reduce the requirement. Often the client wants a number, not a report. A number can be exposed through the Analytics API into a tool they already use. This is the answer more often than it sounds.

Move the work outside HubSpot. If the reporting requirement is genuinely heavy, HubSpot is not the reporting layer and pretending otherwise is expensive. Pull data out and report on it elsewhere, and keep HubSpot as the system of record. Our white-label API integration work is very often this shape: not automating HubSpot's interface, but connecting it to something better suited.

Quote the manual build honestly. Sometimes the client needs those forty reports inside HubSpot where their team already works. That is a real project with real hours, and quoting it as such is better than discovering it mid-delivery.

The bottom line

The public API creates records, schema, pipelines, lists, workflows, forms, emails, HubDB and content. It does not create reports or dashboards, which is why no migration tool moves them and why reporting is always manual rebuild work.

Split your quotes at that boundary, count the reports that are actually used rather than the ones that exist, and check the endpoint before you promise the automation.

If you are scoping technical HubSpot work and would rather have someone confirm what is genuinely automatable before the quote goes out, that is exactly what our white-label agency services exist for. Our post on why the HubSpot Salesforce sync does not backfill history covers the data side of the same boundary.