QAD and Fishbowl integration

What moves between them

The main flow runs from Fishbowl into QAD. ml-connector reads Fishbowl vendors and purchase orders and creates the matching suppliers and purchase orders in QAD, and reads the receiving activity Fishbowl records when stock arrives so the corresponding goods receipts and supplier invoices can be posted in QAD. Because QAD enforces a three-way match, supplier invoices are only posted after the related goods receipt exists, which Fishbowl tracks against the purchase order. Part numbers and vendor records are aligned so every purchase line references an item and supplier that already exists in QAD. QAD owns the general ledger and Fishbowl has no GL account API, so ml-connector never writes accounts or financial entries back into Fishbowl, and item and inventory reference data can be pushed from QAD into Fishbowl through its import endpoint where the customer wants the catalog kept in step.

How ml-connector handles it

ml-connector stores both credential sets encrypted and signs into Fishbowl by posting the app name, app id, username, and password to its login endpoint, then attaches the returned UUID as a Bearer token on every request and logs in again when a call returns an auth error, since the token has no documented expiry. On the QAD side it accepts the full tenant URL per customer, since QAD publishes no shared base address, and refreshes the QAD bearer token when a call returns 401. Because Fishbowl runs on the customer's own server and offers no webhooks, and QAD cloud is also pull-only, it polls the Fishbowl purchase order, vendor, and inventory endpoints on a schedule using the pageNumber and pageSize parameters, and reads entities without a REST path, such as customers, through the Fishbowl data-query SQL endpoint. Vendors and part numbers are mapped first, so every line posted into QAD references a supplier and item that already exists there, and supplier invoices are held until the matching goods receipt is present to respect the QAD three-way match. Fishbowl has no idempotency header, so ml-connector relies on natural keys such as the vendor name and purchase order number to avoid duplicates, and because many Fishbowl servers sit behind a firewall on plain HTTP it supports an on-premise polling agent and backs off on server errors with exponential backoff and jitter. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized discrete manufacturer with around two hundred staff runs QAD Adaptive ERP for production planning, costing, and finance, and uses Fishbowl Advanced on a server in the warehouse to manage parts, vendor purchase orders, and receiving. Before the integration, the buying and receiving teams raised purchase orders and booked in deliveries in Fishbowl, then the finance team re-keyed the same vendors, purchase orders, and bills into QAD by hand, which slowed month-end close and produced mismatches between received goods and posted invoices. With QAD and Fishbowl connected, vendors and purchasing flow into QAD automatically, supplier invoices post only after the goods receipt is in place, and each line lands on the right item and account. The duplicate data entry is gone and the accounts payable figures reconcile against what was actually received from the first day of close.

What you can do

• •Create QAD suppliers, purchase orders, supplier invoices, and goods receipts from Fishbowl vendors and purchasing activity.
• •Hold supplier invoices in QAD until the matching Fishbowl goods receipt exists, to respect the QAD three-way match.
• •Read Fishbowl entities without a REST path, such as customers, through the data-query SQL endpoint, and write reference data through the import endpoint.
• •Authenticate Fishbowl with its session-token Bearer login against each customer's own server URL, and QAD with its tenant-specific token.
• •Poll Fishbowl on a schedule with an optional on-premise agent, natural-key dedup, server-error backoff, and a full audit trail on every record.

Questions

Which direction does data move between QAD and Fishbowl?

The main flow is Fishbowl into QAD. Vendors, purchase orders, and goods receipts move from Fishbowl into QAD as suppliers, purchase orders, supplier invoices, and receipts, while item and inventory reference data can be pushed from QAD into Fishbowl through its import endpoint. Fishbowl has no GL account API and QAD owns the general ledger, so ml-connector never writes accounts or financial entries back into Fishbowl.

How does the integration connect to an on-premise Fishbowl server?

Fishbowl is on-premise software, so each customer runs the REST API on their own server at their own host and port rather than a shared cloud address. ml-connector takes that server URL as a per-customer setting and signs in with the Fishbowl session-token login. For servers behind a firewall it supports an on-premise polling agent so the connector does not need the Fishbowl port exposed to the internet.

Why does the integration poll Fishbowl instead of using webhooks?

The Fishbowl Advanced REST API has no outbound webhooks, no event subscription, and no signature scheme, so there is no reliable push to listen for. QAD cloud is also pull-only and has no webhook system for connectors. For these reasons ml-connector polls the Fishbowl purchase order, vendor, and inventory endpoints on a schedule using the pageNumber and pageSize parameters, and uses the data-query SQL endpoint for entities that lack a dedicated REST path.