Connect HubSpot to Neblex CPQ

Sales runs its pipeline in HubSpot. Product rules, price lists, and the approval matrix live in Neblex CPQ. Without a link, a rep re-types the company, contact, and deal into the quoting tool, then re-types the quote number and total back onto the deal. Companies get duplicated, the deal amount trails the priced quote, and the pipeline report is only as good as the last manual update.

Neblex CPQ has no HubSpot connector of its own, by design. It exposes every customer and quote operation through its API and records every meaningful change in a pull-based event feed that the consumer fetches and acknowledges. Neblex Integration Fabric supplies the other half: a HubSpot connector with 336 operations and 48 polled triggers, association-aware reads, and a visual flow that maps fields, matches records, pauses for a person where needed, and writes the result back.

HubSpot owns the company, the contact, and the deal. CPQ owns the configuration, the price, the approval, and the quote record. Neither side edits what the other owns.

On the CPQ side there are two surfaces. The first is the API, reached through the Neblex CPQ connector in Integration Fabric, which carries 286 operations. This flow uses postapi_customers_list to find an existing customer, postapi_customers, postapi_customer_addresses, and postapi_customer_contacts to create one, postapi_quotes for the quote header, putapi_quotes_id for the line items, and getapi_quotes_id to read the total. Every call clears the four mandatory access layers and the token's per-module scopes before any business logic runs.

The second surface is the event feed. An event listener subscribes a service account to the event types the flow needs: QUOTE_CREATED, QUOTE_STATUS_CHANGED, and QUOTE_VERSION_CREATED, which are append-only, one ordered row per occurrence, and QUOTE_UPDATED, which is coalesced to the latest state of the quote. CPQ offers no push webhooks. The flow fetches with postapi_integrations_listeners_id_events_fetch on the schedule you set, processes the batch, and acknowledges it with postapi_integrations_listeners_id_events_ack.

On the HubSpot side, the Integration Fabric connector authenticates with a private app token or an OAuth 2.0 grant, scoped per object. Deals are object type 0-3, so the flow starts from the changed_get_crm_v3_objects_0_3_getPage trigger, polled on the schedule you set. It reads the deal with get_crm_v3_objects_0_3_dealId_getById, walks its associations with get_crm_v4_objects_objectType_objectId_associations_toObjectType_getPage, reads the company with get_crm_v3_objects_companies_companyId_getById, batches the line items with post_crm_v3_objects_line_items_batch_read_read, and writes back with patch_crm_v3_objects_0_3_dealId_update. None of the 48 HubSpot triggers deliver webhooks; HubSpot's own webhook subscriptions can call a Neblex webhook endpoint for an event-driven start instead.

Between them sits the flow: mapping, matching, optional approval, and a run log.

Triggered on the deal stage change, matched on the deal ID, safe to run twice.

1. 1Trigger. The polled deal trigger fires when dealstage reaches the stage you pick, for example Presentation Scheduled. The flow reads the deal and walks its associations to the company, contacts, and line items.
2. 2Idempotency. If the custom deal property neblex_quote_id is already populated, the quote exists and the run stops, so a re-fired trigger is harmless.
3. 3Resolve the customer. postapi_customers_list searches CPQ for a customer whose customerNumber equals the company's hs_object_id. If none is found, postapi_customers creates the customer, postapi_customer_addresses creates a BILL_TO address from the company address fields, and postapi_customer_contacts creates the primary contact. CPQ records CUSTOMER_CREATED in the feed.
4. 4Create the quote. postapi_quotes creates the quote header with quoteName from dealname, currency from deal_currency_code, validUntil from closedate, and the custCustomerId, custContactId, and custBillToId references from step 3. The deal ID is stored in customFieldValues. Then putapi_quotes_id writes one line per HubSpot line item, keyed on hs_sku as partNumber. CPQ records QUOTE_CREATED.
5. 5Write the number back. patch_crm_v3_objects_0_3_dealId_update sets neblex_quote_id and neblex_quote_number on the deal, so the rep can open the quote from HubSpot.
6. 6The rep works the quote in CPQ. Configurable products are built in the product configurator, pricing rules apply, and a discount past your threshold moves the quote to Needs Approval and locks it. Each stage move records QUOTE_STATUS_CHANGED with fromStatus and toStatus.
7. 7Status back. When the polled fetch returns a QUOTE_STATUS_CHANGED event, the flow reads the quote with getapi_quotes_id, then patch_crm_v3_objects_0_3_dealId_update sets neblex_quote_status to toStatus and amount to totalPrice. When toStatus is your closed-won snapshot status, the flow can also move dealstage to closedwon. It then acknowledges the event by lastEventId.
8. 8Optional gate. If the quote total is over your threshold, the flow pauses for a named approver in Integration Fabric before it moves the deal stage. On reject, it logs a note on the deal and stops.

The starting map for the deal to quote step. Every CPQ field named here exists on the customer, address, contact, quote, or line item record.

HubSpot to Neblex CPQ

• Customers. Company name, domain, industry, and a stable customer number, created once, matched afterward.
• Addresses and contacts. The company address as BILL_TO, and the primary associated contact.
• Quote header. Name, currency, validity date, and the customer, contact, and bill-to references.
• Line items. Standard products from the deal's line items, keyed on SKU as part number.

Neblex CPQ to HubSpot

• Quote identity. The CPQ quote ID and quote number, written to the deal on creation.
• Status. Every stage move, from QUOTE_STATUS_CHANGED, including the closed-won snapshot status.
• Amount. The quote total, read after each status event, so the pipeline follows the priced quote.

• Service account scopes. The flow authenticates to CPQ as a service account, not a user. Its token starts with every action disabled on every module, and an administrator enables only read, create, and update on the customer and quote modules. Disabling the account revokes every token beneath it in one step.
• Four layers on every call. Environment header, client certificate, bearer token, and the optional IP allowance, checked in that order, before scopes are evaluated.
• Event acknowledgment. Events are delivered at least once until the flow acknowledges them, so a run that fails mid-batch sees the same events again, and the cursor never regresses. A coalesced QUOTE_UPDATED record that changed between fetch and acknowledgment is marked stale and arrives again on the next fetch.
• Approvals in the flow. Discount and margin approvals run inside CPQ, where the quote locks until an approver acts. CRM-side thresholds, such as a large deal stage change, pause in Integration Fabric for a named approver.
• Run history. Every run records the deal, the customer it resolved, the lines it mapped, and each CPQ and HubSpot response, and can be replayed from the failed step without re-creating the quote.
• Audit log. CPQ writes an audit entry for every create and update the service account makes, under the service account's name. Each token records when it was last used, so a dormant credential is easy to find and revoke.