HubSpot + Zucchetti integration

Zucchetti sells several ERPs, and this page covers the three a buyer searching for Ad Hoc or Infinity means. Ad Hoc Revolution is the modular client and server system Zucchetti sells to medium and large firms. Ad Hoc Revolution Web serves small and medium firms on Zucchetti’s Infinity technology, installed in the company or run in Zucchetti’s datacenter. Ad Hoc Infinity is the web ERP inside the Infinity Zucchetti suite, aimed at medium and large firms.

The project that reaches us starts the same way whichever product it is. A sales team outside Italy works in HubSpot, the parent company’s orders and invoices live in Ad Hoc, and nobody on the sales side can see them without asking. Zucchetti sells a CRM of its own, Infinity CRM, but a team that already sells from HubSpot has reasons to keep it, and asks for the ERP to be connected instead.

What sets Zucchetti apart from most systems on this site is where the integration facts live. Zucchetti says Ad Hoc Revolution integrates with other software, and its Ad Hoc Revolution Web brochure says the product is built to integrate Zucchetti and third-party solutions. The interface itself is documented only to the distributors who sell and support these ERPs, not on Zucchetti’s public site, and Zucchetti recommends that companies work through its Top Partner ERP network. Nothing public says which protocol that interface speaks or how it authenticates, so this page assumes neither. The honest first step is a scoping call with your partner, where the interface, its authentication and its limits come onto the table before anyone estimates hours with confidence.

Three objects carry the value in a first build. Customers become HubSpot companies, customer orders become deals, and invoices and credit notes land on a custom object associated to the company. Together they answer what sellers ask about an account: what it has ordered and what has been invoiced. Items, prices and stock stay out of a first build, because only the partner’s documentation says which of them the interface exposes at all.

Keys come from the ERP, never from names. A customer keys on its code in Ad Hoc, held in a custom HubSpot property. Orders and invoices key on their document numbers scoped by company and year, so that numbering which restarts for a new year or a second company can never merge two documents.

Everything moves one way at first. The ERP owns the customer ledger and every document, so HubSpot shows them read only. A write back, such as a won deal creating a customer, waits until the partner confirms which calls the installation exposes for writing and who approves them.

The expected shape is a polling sync, pending the partner’s documentation. A service reads customers, orders and invoices on a schedule through the interface the partner documents, keeps a watermark or a fingerprint per record, and upserts only what changed into HubSpot as batches keyed on the ERP’s codes, followed by a separate association pass. Which of the two it keeps depends on whether the interface can return only the records changed since a date, and nothing public says.

State lives in the service: the last good run per object and a replay endpoint that re-reads one object on demand. Where the service runs depends on where the ERP runs. An installation in the customer’s building needs the service inside the network or a secure route into it, and a datacenter installation needs whatever access Zucchetti grants there. Both questions go into the first call with the partner.

What decides the route here is documentation, not budget. Until the partner shares the interface reference for your Ad Hoc or Infinity installation, no connector can be configured and no build can be estimated with confidence.

The documentation has to settle four things before the route is fixed: the protocol, how the interface authenticates, which of customers, orders and invoices it exposes, and whether it can return only what changed since a date. Where the ERP runs matters as well, because an installation in Zucchetti’s datacenter is reached on the terms Zucchetti grants.

Once it is shared, a service we build is the route that fits every Zucchetti ERP, because it adapts to whichever interface the product exposes, and it can carry the write back later. The HubSpot App Marketplace has nothing to install: a search for Zucchetti returns no results.

1. Scope. The first call includes your Zucchetti partner. We confirm the product, the version, where it runs and which interface documentation the partner can share.
2. Architect. We fix the objects, the keys, the change detection and the direction of each object, then write the mapping in English.
3. Build. The service is written against a test company on the partner’s installation, with a HubSpot portal allowlist from the first commit.
4. Validate. We reload every object into a HubSpot sandbox and reconcile counts and open order totals against the ERP.
5. Operate. We watch the run history, keep the replay endpoint ready and re-check the mapping after each Zucchetti update.