HubSpot integrations: understanding standard and non-standard connections
Understand what makes a HubSpot integration standard or non-standard and how custom logic, middleware and third-party systems affect delivery.
When connecting HubSpot with another system, the work can range from installing a supported application to designing and maintaining a bespoke data integration.
Understanding whether an integration is standard or non-standard helps establish realistic expectations around scope, cost, timescale, risk and ongoing ownership.
These are practical delivery classifications rather than formal HubSpot product categories. The classification describes the work required to meet your organisation’s specific requirements, not simply the name of the external platform.
What is a standard integration?
A standard integration uses an existing, supported connection without requiring bespoke development or substantial changes to its intended behaviour.
This will normally be a HubSpot-built connection, an application available through the HubSpot App Marketplace or a supported Data Sync connection.
Examples may include integrations with:
- Google Workspace
- Microsoft 365
- Slack
- Microsoft Teams
- Zoom
- Advertising platforms
- Stripe
- Supported accounting or ecommerce applications
The existence of a Marketplace application does not automatically make every implementation standard. It remains standard only when the available functionality meets the agreed requirement without custom code, complex workarounds or significant additional design.
Characteristics of a standard integration
A standard integration will normally have:
- A pre-built connector
- Documented installation and configuration steps
- Defined objects and fields that can be synchronised
- Predictable authentication and permission requirements
- Supported synchronisation rules
- Limited or no custom development
- Lower implementation and maintenance effort than a bespoke connection
Standard integrations can usually be implemented more quickly because the connector already exists. However, configuration, testing, data mapping and governance decisions may still be required.
What should be checked before calling an integration standard?
Before treating an integration as standard, confirm:
- The required HubSpot and external system subscriptions
- The objects and records supported by the connector
- The fields available for synchronisation
- Whether the data flow is one-way or bidirectional
- How records are matched
- How duplicates and conflicts are handled
- How frequently data synchronises
- Which permissions are required
- Whether historical data is included
- Whether the connector supports the required automation
- Who provides technical support
- Whether additional licensing or usage fees apply
If the available connector does not meet a material requirement, the work may become non-standard even though the application itself appears in the HubSpot App Marketplace.
Examples of standard integration requirements
A requirement is more likely to remain standard when it follows the connector’s documented functionality.
Examples might include:
- Connecting an individual Gmail or Outlook inbox
- Connecting a supported calendar to the meetings tool
- Sending supported HubSpot notifications to Slack or Microsoft Teams
- Adding Zoom details to HubSpot meetings
- Connecting an advertising account using HubSpot’s standard connection
- Connecting Stripe as a supported payment processor
- Synchronising supported records and fields through an existing Data Sync application
The exact capability and subscription requirements should always be checked for the specific application.
What is a non-standard integration?
A non-standard integration goes beyond the supported behaviour of an existing connector or requires a custom technical solution.
It may use:
- HubSpot APIs
- Webhooks
- A custom HubSpot application
- Bespoke field mappings
- Data transformation logic
- Middleware
- Custom authentication
- An integration layer hosted in another platform
Non-standard integrations normally require technical discovery, solution design, development, testing and ongoing support.
Examples of non-standard requirements
An integration is more likely to be non-standard when it involves:
- Connecting a system with no suitable Marketplace application
- Synchronising custom objects unsupported by the standard connector
- Complex bidirectional synchronisation
- Conditional field mappings
- Combining information from several source records
- Transforming data between different formats or structures
- Creating bespoke record-matching rules
- Applying business-specific conflict resolution
- Connecting several systems within one process
- Supporting near-real-time updates through webhooks
- Building custom actions or interfaces inside HubSpot
- Integrating a heavily customised ERP, finance or legacy system
A common external platform can still result in a non-standard integration if the required data flow or business logic is unusual.
Standard platform, non-standard requirement
The platform being integrated does not determine the classification by itself.
For example, connecting a supported accounting platform using its documented connector may be standard. Requiring the same platform to synchronise custom transaction structures, apply bespoke allocation rules and update custom HubSpot objects may be non-standard.
Similarly, a standard Salesforce connector does not make every Salesforce integration straightforward. A heavily customised Salesforce environment may introduce:
- Custom objects
- Bespoke fields
- Complex automation
- Unusual relationships
- Conflicting ownership rules
- Large historical datasets
The requirement must therefore be assessed against the connector’s actual capabilities.
What is middleware?
Middleware is a platform or technical layer positioned between HubSpot and one or more other systems.
Examples include:
- Zapier
- Make
- Workato
- Tray.io
- Custom integration services hosted in AWS or Microsoft Azure
Middleware can receive information from one system, transform it, apply rules and send it to another.
It can be useful when:
- No suitable direct connection exists
- Several systems need to participate in one process
- Information must be transformed
- Routing depends on conditional logic
- A central integration layer is required
- Direct point-to-point integrations would be difficult to maintain
Middleware is not automatically simpler than a custom integration. It introduces another platform with its own licences, credentials, permissions, limits, monitoring and maintenance requirements.
A simple middleware workflow may be relatively low effort. A business-critical, multi-system process built in middleware should be treated as a designed and supported integration solution.
Third-party systems
A third-party system is any external platform being connected to HubSpot. It is not a separate integration method.
A third-party system might be connected through:
- A HubSpot-built connection
- A Marketplace application
- HubSpot Data Sync
- Middleware
- A custom API integration
Examples of third-party systems include:
- ERP platforms such as NetSuite, SAP or Microsoft Dynamics
- Accounting platforms such as Xero or QuickBooks
- Ecommerce platforms such as Shopify or Adobe Commerce
- Data warehouses such as Snowflake or BigQuery
- Specialist service or operational platforms
- Bespoke internal systems
Each external system has its own data model, permissions, APIs, limitations and commercial arrangements.
Comparing the approaches
| Area | Standard integration | Non-standard integration | Middleware solution |
|---|---|---|---|
| Connector | Existing supported connection | Custom or substantially extended | Middleware platform connects the systems |
| Development | Usually limited | Normally required | Varies from configuration to complex development |
| Implementation effort | Usually lower | Usually higher | Depends on workflow complexity |
| Flexibility | Limited to supported features | Designed for specific requirements | Flexible within platform capabilities |
| Maintenance | Primarily connector configuration | Requires technical ownership | Requires platform and workflow ownership |
| Licensing | May be included or separately charged | Development and hosting costs may apply | Separate middleware fees often apply |
| Risk | More predictable | Depends on design and testing | Depends on workflow and platform design |
| Support | HubSpot or app provider | Internal team or development partner | Middleware provider and solution owner |
Scope and cost considerations
Standard integrations can still require professional services for:
- Requirements review
- Configuration
- Field mapping
- Data preparation
- Permission setup
- Testing
- User guidance
- Troubleshooting
Non-standard integrations commonly require additional work for:
- Technical discovery
- Solution architecture
- Development
- Authentication
- Data transformation
- Error handling
- Quality assurance
- User acceptance testing
- Documentation
- Deployment
- Monitoring
- Ongoing maintenance
Additional platform, middleware, hosting or provider costs may also apply.
The integration should be assessed before its scope, delivery approach and cost are confirmed. A platform name alone is not enough to estimate the work reliably.
Data ownership and source-of-truth decisions
Every integration needs clear ownership rules.
For each type of data, decide:
- Which system owns the definitive value
- Which system can create records
- Which system can update records
- Whether the flow is one-way or bidirectional
- What happens when values conflict
- How duplicates are prevented
- How deletions and archived records are handled
- How failed updates are corrected
A third-party system may be the source of truth for some information while HubSpot owns other information.
For example, an ERP may own invoice and fulfilment data while HubSpot owns sales qualification and customer engagement information.
Security and governance
Integrations can provide external applications with access to CRM and customer information.
Your organisation should review:
- The permissions and API scopes being requested
- The information the integration can read or change
- Who can install or configure the connection
- Where credentials and secrets are stored
- Supplier security and data protection arrangements
- International data transfers
- Data retention and deletion
- Logging and audit requirements
- Processes for removing access
Access should follow the principle of least privilege. An integration should receive only the permissions needed for its approved purpose.
Testing and ongoing support
Every integration should be tested before wider rollout, including standard connections.
Testing should cover:
- Record creation and updates
- Field mappings
- Associations
- Duplicate prevention
- Empty and invalid values
- Synchronisation conflicts
- Automation triggered by integrated data
- Error handling
- Permissions
- Reporting
- Disconnection and recovery
Business-critical integrations also need an identified owner and an agreed monitoring process.
An integration is not complete simply because the initial connection succeeds. Its data quality, errors, credentials, provider updates and continued business relevance should be reviewed throughout its lifecycle.
What can Forbidden help with?
Forbidden can help you:
- Determine whether a requirement is standard or non-standard
- Review available HubSpot Marketplace and Data Sync options
- Compare direct, middleware and custom approaches
- Define sources of truth and data ownership
- Document field mappings and synchronisation rules
- Scope custom integration requirements
- Configure and test supported integrations
- Review permissions and governance considerations
- Identify monitoring and support requirements
Where a requirement involves additional development, middleware, licensing or specialist support, Forbidden can help define the approach and provide a clear scope before additional work begins.
Your organisation remains responsible for approving suppliers, security requirements, data protection decisions and additional technology costs.
Further information