Integrations
HubSpot integrations
123 systems this practice connects to HubSpot, across ERP and finance, CRM, delivery, marketing, support, commerce, data platforms and industry software. Each entry states the decision the integration actually turns on, which is ordinarily a question about ownership rather than about endpoints.
21 carry a link to a published case study documenting that specific engagement. The rest are systems built against without one written up.
123 of 123 shown
Tax determination left with the system that owns it, referenced rather than copied.
The hour sold and the hour delivered made the same object across both systems.
Matters modelled one-to-many against the engagement, not one-to-one.
Customer, item and order records mapped to HubSpot objects rather than mirrored wholesale.
Manufacturing and distribution records exposed to the commercial team read-only.
Audience membership driven by CRM state, and closed revenue posted back so bidding sees revenue rather than form fills.
Built to a regulatory constraint where the packaged connector could not meet it.
Order-to-cash across the boundary, with field ownership decided per object.
Reservations, stays and guest history joined to the account, with the booker and the guest kept apart.
Documents generated from CRM data, with an approval gate before send.
Invoices and payments against the deal, with identity reconciled before anything syncs.
Spend against an account joined to the revenue it supports.
Recognised revenue and project accounting read back to the account record.
Coexistence or migration, with a system of record agreed per field before anything moves.
A bounded interface across a system with its own change-control regime.
Ticketing and attendance resolved to one fan record, with the buyer distinguished from the attendee.
Enterprise workflow kept where it belongs, with the commercial record joined to it rather than duplicated into it.
Alerts routed by consequence, with a retirement rule so the channel stays read.
Point-of-sale activity attached to the customer record.
Migration with redirects mapped one to one and verified after cutover.
Migration with a rehearsal, a reconciliation and a documented rollback position.
Project and inventory data joined to the opportunity that produced it.
Order events resolved against an existing contact before creating one.
Self-hosted extraction where data residency is a requirement.
Call outcomes logged as data rather than as a recording nobody opens.
The spreadsheet that became a system, mapped properly on the way in.
Document and export custody inside an account the client controls.
Engagement signals joined to the account, deduplicated on arrival.
Policies and renewals surfaced where the relationship is worked.
Delivery projects provisioned at close, from the scope that was actually sold.
Relational records reconciled against HubSpot associations.
Middleware run in the client's own tenancy where custody matters.
Catalogue and order history reconciled to one customer.
Modelled tables read back into HubSpot as properties, not as dashboards.
Professional-services time and billing joined to the opportunity.
Payables and receivables state visible where the relationship is managed.
Donor history joined without overwriting constituent definitions.
Card and expense data reconciled to the customer record.
Construction projects joined to the deal and its change orders.
Bookings resolved to an existing contact before a new one is made.
Subscription lifecycle events written to the deal and the company.
Call analysis surfaced on the record rather than in a second tab.
Forecast submissions read against the pipeline that produced them.
Enrichment written to named properties rather than over whatever it finds.
Call and sequence history retained against the contact.
Agreements and tickets reconciled with the commercial record.
List history preserved through consolidation.
Google-native records mapped onto HubSpot's object model.
Scores and segments written to named fields with a documented refresh.
Metric logic held in one tested place rather than in each report.
Relationship and coverage data joined to the commercial pipeline.
Transcripts and dispositions written back to the contact.
Envelope state moving the deal rather than a person remembering to.
Registrations and attendance recorded as separate facts, because they are.
Scheduling, dispatch and routing joined to the deal that funds the visit.
Managed extraction with schema drift treated as a scheduled task.
Service history read against the renewal it will influence.
Conversation signals attached to the deal, with retention agreed first.
Offline conversions returned so bidding sees revenue rather than form fills.
Recognised as a system of record where it genuinely is one.
Contracts and time joined to the account they bill.
Tracked time reconciled to the agreement it is billed against.
Mailbox threads attached to the record they concern.
Industry CloudSuite data surfaced against the account it belongs to.
Projects and opportunities separated on arrival rather than merged.
Conversation history joined to the contact, with identity resolved first.
Issues linked to the account without exposing the backlog to the commercial team.
Field jobs and quotes surfaced against the customer record.
Campaign and contact history preserved through the move.
Commerce behaviour joined to the contact without duplicating consent.
Tiles embedded where the work happens rather than in a separate portal.
Audience and subscription state reconciled with HubSpot's own.
Scenario ownership and error handling agreed at design time.
Programme membership and scoring migrated with the definitions intact.
Subscription billing and revenue schedules read against the deal.
Conversions API fed from closed revenue instead of page events.
Notifications scoped to the people who can act on them.
Bookings and memberships joined to the customer record.
Territory and geography as a layer over the CRM, so location is a dimension rather than a text field.
Board columns mapped to properties with types decided rather than inferred.
Boards created per engagement with ownership set at provisioning.
Client documentation linked from the record rather than pasted into it.
Modules selected per requirement instead of syncing the whole estate.
Sequence state kept in one place instead of two competing ones.
Incident history surfaced where the relationship is managed.
Payment confirmation joined to the deal it settles.
Pipeline and activity history carried across without flattening the stage model.
Reporting built on a defined semantic layer instead of raw exports.
Enrolment and family records reconciled to one contact.
Project financials read back without moving the system of record.
Churn and dunning state visible before the renewal conversation.
Automated portal health checks on data quality and configuration, run on a schedule rather than before a renewal.
Configure, price and quote against the HubSpot object model, so a quote is a record rather than a PDF nobody can report on.
The go-to-market record: people, coverage and the tech estate, held where the revenue data already is.
The managed integration layer this practice builds on, where rate limits, retries and schema drift are an operator's obligation rather than the client's.
Closed deals provisioned into delivery work, from the scope that was sold rather than a re-keyed summary.
Telephony activity attached to the record it belongs to.
Cadence membership and outcomes reflected on the contact.
Team scheduling resolved against HubSpot contacts and meetings rather than a parallel calendar.
Identity resolution decided before events start flowing.
Jobs and estimates reconciled with the pipeline that created them.
Orders and lifetime value joined to the contact, refunds included.
Schedules and resourcing read against the deal that funds them.
CRM data landed in the warehouse with a stated grain and refresh.
Subscription and payment state on the record, priced server-side.
Custom modules resolved to objects rather than dropped into notes.
Metric definitions agreed once and reused on both sides.
Governed workflows where the estate has outgrown point automation.
Messaging with consent state held in one place.
Form submissions and page activity resolved to a single contact.
Store data mapped to objects rather than dropped into properties.
Recipes with centralised observability rather than per-flow logging.
Delivery status reflected on the account without duplicating the plan.
Invoice status and payment date surfaced without leaving the deal.
Suited to edge automation; not to a load-bearing connection.
Ticket state visible on the account without two support queues.
Meeting outcomes recorded against the deal they advance.
Attendance duration written back, not merely registration.
What an integration is actually deciding
The tool is the last decision rather than the first. Before a connector is chosen, three questions have to be answered: how a record in one system is known to be the same record in the other, which system wins when both write the same field, and how a silent failure becomes visible. Those answers hold whichever platform is selected, and an integration that skips them works for a quarter and is distrusted by the third.
The full argument, including where a native connector is the correct answer and where it stops being one, is set out in the integration architecture white paper, which is free to read.
Common Questions
Frequently Asked Questions
It means the system is one this practice builds against. Where a published case study documents that specific engagement, the entry carries a link to it, and eleven of them do. The absence of a link means there is no published study, not that the work has not been done.
The directory is not exhaustive and is not intended to be. A system with a documented API is ordinarily integrable, and a system without one usually has a database, a scheduled export or a file drop that can be treated as an interface. The listing exists to show the range rather than to bound it.
Almost always, and it is the first thing assessed. Where the packaged connector's assumptions match the business, it costs least, is maintained by someone else, and fails in ways shared with thousands of other portals. Custom work is warranted where the object model cannot be expressed in it — project-level costing, a regulatory constraint on where data may travel, a second system writing to the same field.
Three decisions taken before any connector is chosen. Record identity, because no two commercial systems share an identifier space. A system of record per field, so a value written by both sides has a defined winner. And observability, because the integration failures that cost trust are the silent ones: a paused schedule or an expired credential, where records stop moving while both systems report themselves healthy.
Not for the same field. They can for different fields on the same object, which is the ordinary arrangement: legal name and payment terms owned by finance, relationship data owned by the CRM. What cannot hold is two systems writing one field without a stated conflict policy, and that is the condition most often discovered after a figure has been presented externally and found to be wrong.
With the field ownership map, the identity rule, the conflict policy and the monitoring, in writing. An integration nobody can explain is an integration nobody can repair, and the documentation is what separates a working system from a dependency on whoever built it.
A system not listed here
The directory shows range rather than limits. A scoped integration build is quoted from the object model on each side and the fields that have to cross between them.