HubSpot Price Books API: Keeping CRM Pricing in Sync With Your ERP

A sales rep opens a deal in HubSpot and builds a quote using a price that was correct three weeks ago. The ERP has since been updated, but HubSpot still shows the old price.

The rep applies a standard discount, the quote stays within the approval threshold, and it goes out without review. Everyone followed the defined process. The problem was that the process started with outdated pricing.

On July 24, 2026, HubSpot announced that the Price Books API had entered public beta.

Price Books were already available through the Revenue Hub interface, giving teams a way to maintain different catalogs for regions, customer types, currencies, or sales channels. The API allows an ERP, PIM, or another pricing system to create and manage those catalogs programmatically.

Companies that currently copy prices into HubSpot by hand can now build a controlled synchronization process.

Price Books are available with Revenue Hub Professional and Enterprise. The API remains in beta.

What the API supports#

An integration can use the Price Books API to create a price book, add products from HubSpot's product library, set prices, validate the catalog, and activate it.

A price book can also be associated with a deal through HubSpot's Associations API.

This is useful for companies with several valid prices for the same product. A North American enterprise customer may use a different catalog from a European distributor. A partner deal may have negotiated pricing that does not apply to a direct customer.

Assignment rules can select the appropriate catalog based on deal or account data, reducing the chance that a rep chooses the wrong one.

The API covers catalog management and deal association. It does not create deal or quote line items directly from price-book items. Those line items are still created through HubSpot's quoting process.

How HubSpot stores the pricing#

An ERP or PIM can remain the authority for pricing, but HubSpot does not query that source live whenever someone opens a deal.

The integration publishes pricing records into HubSpot, where they are stored as price-book items. Keeping those records current requires decisions about synchronization frequency, error handling, and how price changes are released.

A nightly job may be sufficient for a company that updates prices quarterly. A distributor whose costs change throughout the day may need more frequent updates or an event-driven process.

Updating active price books#

HubSpot does not allow products or prices to be changed while a price book is active. The book must be deactivated before it can be updated and validated.

One approach is to update the existing book during a controlled release window. This may work when prices change infrequently and temporary deactivation will not disrupt the sales team.

Another approach is to create a new version for each pricing period:

• North America Enterprise, Q3 2026
• North America Enterprise, Q4 2026
• Partner Pricing, January 2027

New deals can use the latest version while existing deals retain the catalog they started with. This also creates a clearer record of which prices were available at a given time.

The choice depends on how frequently prices change and whether open opportunities should retain their original pricing.

Pricing ownership#

A reliable integration needs one system with final authority over standard catalog pricing.

When the ERP owns pricing, ordinary changes should originate there and flow into HubSpot. Allowing the same catalog prices to be edited independently in both systems makes synchronization ambiguous. The integration must either overwrite the HubSpot edit, preserve it, or send the discrepancy for review.

Deal-specific exceptions can still be handled inside HubSpot. A rep may need a custom line item or an approved price for a particular customer. Those exceptions should remain separate from the standard catalog maintained by the source system.

The integration also needs a defined response when HubSpot rejects an update. The job should identify the affected records and alert the team responsible for pricing. For higher-risk catalogs, the process can validate the complete update before making it available to sales.

Synchronization triggers#

Most teams will choose between scheduled and event-driven updates.

A scheduled process runs at a fixed interval and compares the source catalog with the records in HubSpot. It is generally easier to build and support.

An event-driven process starts when the ERP or PIM records a pricing change. It can keep HubSpot more current, but it depends on the source system exposing a dependable webhook, event stream, or change log.

Some implementations may use both. Events handle routine changes quickly, while a scheduled reconciliation job checks for records that were missed.

The appropriate frequency depends on how quickly a stale price could affect a quote. A few hours may be acceptable for one company and financially significant for another.

Price-book assignment#

Synchronizing the correct prices does not guarantee that a deal will use the correct catalog.

Assignment rules might consider:

• Customer location
• Deal currency
• Account tier
• Sales channel
• Product family
• Contract type

The timing of assignment matters as well. A price book might be selected when a deal is created, when it reaches a particular stage, or immediately before a quote is prepared.

Suppose a distributor's account tier changes while several opportunities remain open. Assigning the price book only at deal creation would leave those opportunities on the old catalog. Re-evaluating the assignment before quoting would move them to the current distributor pricing.

Sales operations and finance should agree on these scenarios before the logic is implemented.

Open deals and pricing changes#

A pricing update raises a separate question: what should happen to opportunities that are already in progress?

Some companies honor the price that was available when the deal was created. Others apply current pricing until a formal quote has been issued. A company may also guarantee a price for a defined number of days.

For example, an unquoted deal could move to the latest catalog automatically, while a deal with a quote already sent retains its existing price book. Another company may allow an older catalog only after sales management approves it.

These decisions affect customer commitments, commissions, margin reporting, and approval workflows. They need to be reflected in both the integration logic and the sales process documentation.

Example: stale pricing and approval thresholds#

Assume the approved list price increases from $10,000 to $11,000 in the ERP.

HubSpot is not updated and continues to show $10,000. A rep applies a 10% discount and sends a quote for $9,000.

HubSpot evaluates the quote as a standard 10% discount, so the approval workflow does not involve a manager. Compared with the current list price, the effective discount is more than 18%.

After the $11,000 price is synchronized, the same $9,000 quote exceeds the standard discount threshold and can be routed for review.

Legacy CPQ migration#

The Price Books API may allow some companies to move catalog management out of an older CPQ platform.

A legacy tool may currently hold pricing because HubSpot lacked a practical way to receive catalogs from the ERP. The API creates a direct integration path between the source system and HubSpot.

Other CPQ functions still need to be evaluated individually. Depending on the platform, these may include product compatibility rules, bundles, guided selling, approval chains, document generation, renewals, and contract amendments.

During a migration, the new process should run alongside the existing tool before cutover. A representative sample of deals can be compared across both systems, including:

• Assigned price book
• Available products
• Unit prices
• Currency
• Discounts
• Final quote total

An API response only confirms that HubSpot accepted the request. Testing real deals confirms whether the new process produces the same pricing result as the system it will replace.

Who should evaluate the beta#

The clearest candidates are companies that already maintain pricing in an ERP, PIM, or another controlled source and currently rely on imports or manual CRM updates.

They already have an authoritative pricing system. The implementation work is primarily about publishing those prices into HubSpot, selecting the correct catalog for each deal, and handling later changes.

The use case is less compelling when HubSpot is the only system where prices are maintained because there is no external catalog to synchronize.

Teams adopting the beta should keep the integration in a dedicated service or module. If HubSpot changes the API before general availability, a contained implementation will be easier to update than API calls spread across workflows and unrelated applications.

For companies already managing pricing outside HubSpot, the API provides a supported route for bringing those catalogs into the CRM without relying on repeated manual entry.