Integrations
HubSpot integrations
112 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.
11 carry a link to a published case study documenting that specific engagement. The rest are systems built against without one written up.
112 of 112 shown
Invoices and payments against the deal, with identity reconciled before anything syncs.
Order-to-cash across the boundary, with field ownership decided per object.
Recognised revenue and project accounting read back to the account record.
Invoice status and payment date surfaced without leaving the deal.
Customer, item and order records mapped to HubSpot objects rather than mirrored wholesale.
Project and inventory data joined to the opportunity that produced it.
A bounded interface across a system with its own change-control regime.
Modules selected per requirement instead of syncing the whole estate.
Manufacturing and distribution records exposed to the commercial team read-only.
Industry CloudSuite data surfaced against the account it belongs to.
Payables and receivables state visible where the relationship is managed.
Tax determination left with the system that owns it, referenced rather than copied.
Spend against an account joined to the revenue it supports.
Card and expense data reconciled to the customer record.
Subscription billing and revenue schedules read against the deal.
Coexistence or migration, with a system of record agreed per field before anything moves.
Migration with a rehearsal, a reconciliation and a documented rollback position.
Built to a regulatory constraint where the packaged connector could not meet it.
Pipeline and activity history carried across without flattening the stage model.
Google-native records mapped onto HubSpot's object model.
Custom modules resolved to objects rather than dropped into notes.
Campaign and contact history preserved through the move.
Projects and opportunities separated on arrival rather than merged.
Call and sequence history retained against the contact.
Board columns mapped to properties with types decided rather than inferred.
Relational records reconciled against HubSpot associations.
Relationship and coverage data joined to the commercial pipeline.
Forecast submissions read against the pipeline that produced them.
Conversation signals attached to the deal, with retention agreed first.
Call analysis surfaced on the record rather than in a second tab.
The hour sold and the hour delivered made the same object across both systems.
Delivery projects provisioned at close, from the scope that was actually sold.
Issues linked to the account without exposing the backlog to the commercial team.
Boards created per engagement with ownership set at provisioning.
Schedules and resourcing read against the deal that funds them.
Delivery status reflected on the account without duplicating the plan.
Client documentation linked from the record rather than pasted into it.
Tracked time reconciled to the agreement it is billed against.
Professional-services time and billing joined to the opportunity.
Jobs and estimates reconciled with the pipeline that created them.
Field jobs and quotes surfaced against the customer record.
Construction projects joined to the deal and its change orders.
Project financials read back without moving the system of record.
Engagement signals joined to the account, deduplicated on arrival.
Enrichment written to named properties rather than over whatever it finds.
Cadence membership and outcomes reflected on the contact.
Sequence state kept in one place instead of two competing ones.
Programme membership and scoring migrated with the definitions intact.
Audience and subscription state reconciled with HubSpot's own.
Commerce behaviour joined to the contact without duplicating consent.
List history preserved through consolidation.
Form submissions and page activity resolved to a single contact.
Migration with redirects mapped one to one and verified after cutover.
Registrations and attendance recorded as separate facts, because they are.
Attendance duration written back, not merely registration.
Audience membership driven by CRM state rather than by a static upload.
Offline conversions returned so bidding sees revenue rather than form fills.
Conversions API fed from closed revenue instead of page events.
Ticket state visible on the account without two support queues.
Conversation history joined to the contact, with identity resolved first.
Service history read against the renewal it will influence.
Mailbox threads attached to the record they concern.
Agreements and tickets reconciled with the commercial record.
Contracts and time joined to the account they bill.
Incident history surfaced where the relationship is managed.
Orders and lifetime value joined to the contact, refunds included.
Subscription and payment state on the record, priced server-side.
Store data mapped to objects rather than dropped into properties.
Catalogue and order history reconciled to one customer.
Order events resolved against an existing contact before creating one.
Subscription lifecycle events written to the deal and the company.
Churn and dunning state visible before the renewal conversation.
Point-of-sale activity attached to the customer record.
Payment confirmation joined to the deal it settles.
CRM data landed in the warehouse with a stated grain and refresh.
Modelled tables read back into HubSpot as properties, not as dashboards.
Scores and segments written to named fields with a documented refresh.
Tiles embedded where the work happens rather than in a separate portal.
Reporting built on a defined semantic layer instead of raw exports.
Metric definitions agreed once and reused on both sides.
Identity resolution decided before events start flowing.
Managed extraction with schema drift treated as a scheduled task.
Self-hosted extraction where data residency is a requirement.
Metric logic held in one tested place rather than in each report.
Suited to edge automation; not to a load-bearing connection.
Scenario ownership and error handling agreed at design time.
Recipes with centralised observability rather than per-flow logging.
Governed workflows where the estate has outgrown point automation.
The spreadsheet that became a system, mapped properly on the way in.
Recognised as a system of record where it genuinely is one.
Document and export custody inside an account the client controls.
Middleware run in the client's own tenancy where custody matters.
Alerts routed by consequence, with a retirement rule so the channel stays read.
Notifications scoped to the people who can act on them.
Call outcomes logged as data rather than as a recording nobody opens.
Telephony activity attached to the record it belongs to.
Transcripts and dispositions written back to the contact.
Messaging with consent state held in one place.
Meeting outcomes recorded against the deal they advance.
Bookings resolved to an existing contact before a new one is made.
Documents generated from CRM data, with an approval gate before send.
Envelope state moving the deal rather than a person remembering to.
Matters modelled one-to-many against the engagement, not one-to-one.
Bookings and memberships joined to the customer record.
Advisory relationships and households resolved on arrival.
Portfolio data referenced without moving custody of it.
Policies and renewals surfaced where the relationship is worked.
Quoting activity joined to the pipeline that produced it.
Technical monitoring integrated rather than duplicated in the CRM.
Device and agreement data joined to the account it bills.
Enrolment and family records reconciled to one contact.
Donor history joined without overwriting constituent definitions.
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.