QAD and Pipedrive integration

What moves between them

The main flow runs from QAD into Pipedrive. ml-connector reads QAD customers and writes them into Pipedrive as organizations, with key contacts created as Pipedrive persons linked to those organizations, and it maps QAD items to Pipedrive products so deals reference the real catalog. In the other direction, Pipedrive deals that reach a won status are read and turned into sales orders in QAD, carrying the deal value, currency, and attached product lines. Reference data such as account identifiers is aligned in both directions so records match on a stable key. Polling cadence is set per entity to fit how often each side changes.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Pipedrive side it sends either the x-api-token header or an OAuth2 Bearer token, refreshing the OAuth access token when a call returns 401, and reads through v2 cursor pagination using the next_cursor value and a limit up to 500. On the QAD side it accepts the full tenant URL per customer, since QAD publishes no shared base address, and validates entity paths against that instance. Because QAD cloud is pull-only, both systems are polled on a schedule rather than waiting for a push. Writes into Pipedrive search for an existing record first and upsert by match, since Pipedrive has no native idempotency key, so a re-run updates the organization or product instead of creating a duplicate. Pipedrive returns HTTP 429 when a burst or daily token budget is exceeded, so ml-connector backs off using x-ratelimit-reset and retries. Custom field keys come back as opaque hashes, so field definitions are read from dealFields and personFields to map them. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized contract manufacturer runs QAD Adaptive ERP for production, procurement, and finance, and its sales team works deals in Pipedrive. Before the integration, reps created organizations in Pipedrive by hand while operations kept the same customers in QAD, so names, addresses, and the product catalog drifted apart, and a won deal had to be re-entered as a QAD sales order by an order desk. With QAD and Pipedrive connected, customer accounts flow into Pipedrive as organizations, the QAD item list appears as Pipedrive products, and a won deal becomes a QAD sales order automatically. Sales and operations work from the same accounts, and the manual order re-entry step is gone.

What you can do

• •Write QAD customers into Pipedrive as organizations, with key people created as linked persons.
• •Map QAD items to Pipedrive products so deals reference the real catalog.
• •Turn won Pipedrive deals into QAD sales orders with value, currency, and product lines.
• •Authenticate Pipedrive with an API token or OAuth2 Bearer token and QAD with its tenant-specific session.
• •Poll both sides on a per-entity schedule, with search-based upsert dedup, retries, and a full audit trail.

Questions

Which direction does data move between QAD and Pipedrive?

The main flow is QAD into Pipedrive. Customers and items move from QAD into Pipedrive as organizations, persons, and products. In the other direction, Pipedrive deals that reach a won status are read and written into QAD as sales orders, so each system holds the records it owns.

Can Pipedrive send invoices or payments into QAD?

No. Pipedrive is a sales CRM and has no native invoices, purchase orders, or payments. ml-connector moves the records Pipedrive does hold, mapping organizations, persons, products, and won deals, and leaves QAD as the system of record for accounting. Invoicing in QAD is driven off the sales order the won deal creates.

How does ml-connector avoid creating duplicate records in Pipedrive?

Pipedrive has no native idempotency key for writes, so ml-connector searches for an existing organization or product first and upserts by match against a stable key carried from QAD. On a re-run the matching record is updated rather than duplicated. When Pipedrive returns HTTP 429 for a rate or daily budget limit, ml-connector backs off using x-ratelimit-reset before retrying.