Acumatica and Pipedrive integration

What moves between them

The primary flow runs from Pipedrive into Acumatica. When a deal reaches a won stage, ml-connector creates or updates the matching Acumatica customer from the linked organization and person, then opens a sales order or sales invoice for the deal value and products. Organizations and persons sync to Acumatica customer and contact records so the CRM and the ledger agree on who the buyer is. In the return direction, ml-connector reads Acumatica sales invoice and balance status and writes it onto the originating Pipedrive deal so sales can see billing progress. Products and items are aligned so deal line items reference SKUs that exist in Acumatica.

How ml-connector handles it

ml-connector stores both credential sets encrypted and runs two OAuth2 logins side by side. On the Acumatica side it accepts the full instance URL and the endpoint version per customer, since a version mismatch returns 404, and it sends every field value in the wrapped value form that the REST API requires. On the Pipedrive side it subscribes to deal, organization, and person webhooks and verifies the X-Pipedrive-Signature HMAC against the unmodified raw body, returning 401 on a bad signature rather than 200. Because Acumatica gives no reliable push, ml-connector polls sales invoices and payments using the LastModifiedDateTime filter and stores a high-water mark between runs. Deal stages map to Acumatica order states, and Pipedrive custom field hashes are resolved to readable names through the field endpoints before mapping. Acumatica throttles at HTTP 429 above its license tier and Pipedrive at 429 against its token budget, so ml-connector backs off with jitter; because neither side has a native idempotency key, it searches for an existing record before creating and dedups on the webhook correlation id so a retried event does not create a duplicate customer or order.

A real-world example

A mid-sized industrial equipment distributor with about 120 staff runs Acumatica for order management, inventory, and AR, and runs Pipedrive for its outside sales team. Before the integration, when a rep marked a deal won, someone in order entry re-typed the company, contact, and line items into Acumatica from the Pipedrive deal, and reps had no view of whether the resulting invoice was paid without asking accounting. With Acumatica and Pipedrive connected, a won deal creates the customer and sales order automatically, and the invoice balance flows back onto the deal, so order entry stops re-keying and reps can see billing status on the record they already work in.

What you can do

• •Turn won Pipedrive deals into Acumatica customers and sales orders without manual re-entry.
• •Sync Pipedrive organizations and persons to Acumatica customer and contact records.
• •Write Acumatica sales invoice and balance status back onto the originating Pipedrive deal.
• •Align Pipedrive products with Acumatica stock and non-stock items so line items match real SKUs.
• •Verify Pipedrive webhook signatures, poll Acumatica on a schedule, and dedup so retried events never create duplicate records.

Questions

Which direction does data move between Acumatica and Pipedrive?

The primary flow is Pipedrive into Acumatica. Won deals, organizations, and persons move from Pipedrive to create customers and sales orders in Acumatica. In the return direction, ml-connector reads Acumatica sales invoice and balance status and writes it onto the matching Pipedrive deal, since Pipedrive has no invoices or payments of its own.

How does the integration get changes if Acumatica has no reliable webhook?

Pipedrive sends real webhooks for deal, organization, and person changes, and ml-connector verifies the HMAC signature on each one. Acumatica push notifications are not guaranteed for connectors, so ml-connector polls Acumatica sales invoices and payments using the LastModifiedDateTime filter and keeps a high-water mark between runs. You set the polling cadence to match how often billing status needs to refresh.

How does it handle Acumatica's version-locked URL and lack of an idempotency key?

ml-connector stores the full Acumatica instance URL and endpoint version per customer, because a version that does not match the running ERP release returns 404. Neither Acumatica nor Pipedrive offers a native idempotency key, so before creating a record ml-connector searches for an existing match and dedups on the webhook correlation id, which stops a retried event from creating a duplicate customer or order.