An integration is a good fit when it can carry the right records, preserve the intended relationships and leave your team able to resolve a failure. A marketplace listing or a successful connection screen does not answer all of those questions. Before choosing native or custom work, write down the behavior your business needs and the evidence each option must provide.
TLDR: Start by checking whether an existing connector supports your objects, fields, associations, direction and exception process. Consider a configurable integration platform or custom code when documented requirements remain unmet. Include maintenance, security review and recovery in the decision, not only initial setup.
Product references checked August 30, 2026. The decision matrix is our evaluation method. It does not rank specific vendors or promise a cost, speed or reliability advantage.
For this guide, “native” means a supported connector already available for the systems you want to connect. That may be built by HubSpot or another vendor. “Configurable platform” means an integration service where you assemble the workflow. “Custom” means code built for your requirements. These are working definitions for procurement, not official HubSpot certification categories.
HubSpot data sync supports one-way or two-way synchronization with supported apps. Its configuration includes field mapping and conflict-resolution choices; custom property mappings have subscription requirements. Verify the exact app and configuration rather than assuming every marketplace integration behaves the same way. HubSpot: data sync configuration.
Our HubSpot integrations overview can help identify systems to investigate. This article focuses on the selection criteria you should apply to a candidate.
Your integration strategy should explain how HubSpot CRM and the external system will share responsibility. An existing native connector may fit a standard exchange. A custom HubSpot integration may be worth evaluating when the required business logic, data transformation or recovery behavior cannot be demonstrated by that connector. Neither choice removes the need to test the result.
Before choosing integration architecture, separate the immediate business need from ideas for later. A project to replace manual data entry for account status does not automatically need to move historical data, rebuild marketing automation and connect a data warehouse. Put those additional data flows in the requirements register and decide which are actually in scope.
The HubSpot App Marketplace is a starting place to investigate available apps, not a guarantee that a particular app can satisfy your integration needs. Ask for the supported-object list and inspect the specific data sync configuration. HubSpot documents paid Data Hub requirements for custom property mappings. Verify that requirement against the proposed connector and your account before choosing a design. HubSpot data sync and field mappings.
Distinguish a marketplace app, its underlying native tools and the services needed to operate it. If the proposed solution combines an app marketplace connector with custom code actions or other automation, ask the provider to identify each component, its eligibility requirements and its maintainer. Do not accept the label “native” as a complete architecture description.
If your requirements involve custom objects, start with a documented record example. Identify the object in each system, its unique identifier and the relationship to contacts, companies or other records. Then verify the actual API and connector coverage. The ability to exchange contact information does not establish that a candidate can preserve every required relationship.
Use the same approach for proprietary systems, legacy systems or an inventory management database. Ask how the external system exposes information, which operations it permits and who supports those interfaces. A custom API design cannot safely assume that another business system offers an endpoint, permission or event that has never been verified.
A proposal for custom API development should name the code owner, deployment environment and person who can investigate an error. Request a diagram of API calls and data storage, plus the current developer platform documentation the builder relied on. Record the authentication approach, whether it uses OAuth, private apps or another supported mechanism, and how access will be reviewed and revoked.
Have the builder explain how API changes will be detected and tested. Ask about the versioning and migration requirements for each selected CRM API or other REST API endpoint. If someone proposes legacy API key authentication, stop for a current documentation check. Do not let an old tutorial silently determine access to customer data.
Connecting HubSpot to other business systems can expose conflicting definitions. Ask which system owns customer data, how blanks should be handled and what happens when the same person or company has different identifiers. Document the data transformation that converts an external value into a valid HubSpot property value.
For example, a fictional billing system might store account state as “A” while the CRM uses “Active.” The acceptance test should cover the approved translation, an unknown code and a later correction. Test the result in the intended business processes, not only in the integration log. An apparently successful transfer is insufficient if the sales team reads the wrong account state.
You do not have to select one implementation style for every connection in your HubSpot instance. In a hypothetical design, an existing connector might handle supported contact updates, while a separately approved custom integration handles a proprietary subscription event. Evaluate each flow independently and define where the two meet.
The important boundary is who may write each value. Avoid two components independently trying to sync data into the same field without a conflict rule. A hybrid design also needs one place to record unresolved exceptions, even if different maintainers support its native integrations and custom solutions. Decide who coordinates an incident that crosses that boundary.
“Sync our CRM and billing system” is too broad to evaluate. We recommend a requirement such as: “Show the approved billing account reference and current account status on the correct company record, without allowing sales edits to replace the billing system's values.”
That statement gives a reviewer something to test. It identifies the object, identity, direction, authority and business purpose. Add the expected update interval and the owner who should investigate an exception.
For every required data flow, document:
Classify each requirement as mandatory, optional or deferred. Do not let several optional conveniences compensate for a missing mandatory relationship.
The table below is an evaluation matrix, not a claim that every option has the listed capability. Ask each provider or builder to demonstrate the requested evidence.
| Decision area | Existing connector | Configurable integration platform | Custom integration |
|---|---|---|---|
| Object and field coverage | Check the exact supported object and mapping list | Check available actions and transformation limits | Require a design tied to documented API capabilities |
| Associations | Demonstrate the relationships your process requires | Demonstrate how related records are resolved | Specify relationship creation, repair and reconciliation |
| Conflicting changes | Review the connector's documented winning-value rule | Inspect the configured rule and its execution order | Require explicit conflict behavior and tests |
| Failed records | Demonstrate the error view and approved retry path | Demonstrate failed-run inspection and replay | Require logs, safe retries and an unresolved-record queue |
| Access | Review the requested permissions | Review platform and connected-app access together | Review the app's requested permissions and secret handling |
| Maintenance | Identify vendor support and your internal operator | Identify who owns the configuration and platform updates | Identify who maintains code, dependencies and API changes |
| Recovery | Test a supported correction or rollback path | Test replay without duplicate business actions | Require a tested recovery procedure and acceptance evidence |
Record each result as supported, unsupported or unverified. Keep the evidence beside it. A sales assurance without a demonstration or relevant documentation should remain unverified.
HubSpot data sync lets you choose a default app for conflicting values, and that choice does not override the selected sync direction. Review those settings together when that connector is your candidate. HubSpot: conflict resolution.
More generally, we recommend deciding authority at the field level. Sales might own a relationship note while a billing system owns an account balance. “Both systems are the source of truth” leaves a conflict unresolved unless the integration has an explicit rule for each value.
Include blank values, simultaneous edits and older updates in the test plan. Ask what happens when a replay arrives after a newer correction. You do not need a particular architecture to ask these questions; you need a provider who can explain and demonstrate the behavior.
Consider a fictional business requirement: an approved account-status change should reach the correct company, while an invalid territory code should be held for review. The operator must be able to correct that one failure without creating a second company or repeating an unrelated action.
We recommend asking each candidate to demonstrate this scenario with approved test records. First run a valid update. Then introduce the invalid value, inspect the failure, correct it and repeat the operation. Verify the final identity, value and relationship.
The exercise can reveal a gap that a feature checklist misses. If the existing connector passes the mandatory test, document that evidence. If it fails, identify the exact missing behavior before moving to another approach. The requirement should determine the next option you evaluate.
HubSpot's API limits vary by app type, account subscription and endpoint; some APIs have their own stricter limits. Exceeding an applicable rate limit can return an HTTP 429 response. A custom design needs to account for the limits that apply to its actual calls. HubSpot: API usage guidelines.
We recommend asking the builder how it will handle retries, duplicate events, partial failures and changes to the external API. Request evidence from tests, not an assurance that custom code is inherently more flexible or reliable.
Also ask who can maintain the integration if the original developer is unavailable. The handoff should include source ownership, deployment instructions, access responsibilities, monitoring and recovery. Detailed security procurement belongs in a separate review before any credentials are issued.
For a HubSpot integration project, request separate responsibilities for implementation, monitoring and ongoing support. Ask how the integration strategy will be reviewed as the business evolves. Native integrations and custom integrations both need an owner when requirements change; the support arrangement should explain who evaluates that change and who authorizes the work.
When comparing HubSpot integration services, ask providers to identify technical debt already present in the design, such as undocumented manual processes or unsupported dependencies. Data complexity can make a small-looking connection expensive to maintain. Compare a custom HubSpot integration with an available connector using the same operating requirements, not only the initial build estimate.
Compare the same scope for each option. Include software charges, implementation, testing, monitoring, support, change requests and the cost of retiring or replacing the integration. Use current quotes and your actual requirements; this article does not supply a universal cost estimate.
We recommend recording the reason an option was rejected as carefully as the reason one was selected. “Cannot preserve the required company association in the tested flow” is actionable. “Too basic” is not specific enough to revisit when the product changes.
Keep unrelated HubSpot operational issues in a separate backlog so the integration decision stays focused on its approved requirements.
We recommend evaluating an existing connector against your mandatory requirements first. Choose it when the evidence supports the required behavior and operating model. Do not assume coverage from the label alone.
Consider it when an important requirement remains unmet by the evaluated alternatives and the business accepts the implementation and maintenance responsibilities. Document the specific gap and test the proposed design.
It may fit some requirements. Evaluate its available actions, transformations, limits and recovery process using the same acceptance tests you apply to the other options.
Include the mandatory requirements, tested evidence, unresolved limitations, accountable operator, current commercial terms and recovery responsibilities. Record the approval before connecting production data.
Our HubSpot operations services can help you turn the business requirement into a reviewable integration scope.
Bring the systems involved, required fields, relationships and one failure scenario when you talk with Selworthy. Those details make the native-versus-custom discussion concrete.