Acumatica and Fishbowl integration

What moves between them

Reference and purchasing data flows from Acumatica into Fishbowl. ml-connector pushes vendors and stock items so the warehouse catalog matches purchasing, then mirrors each approved Acumatica purchase order into Fishbowl using the import and purchase-order endpoints so receiving happens against the correct document. The return flow comes from Fishbowl into Acumatica: goods receipts and inventory counts are read on a schedule and used to post or settle the matching bill in Acumatica against the originating purchase order. Fishbowl owns no chart of accounts, so GL accounts and journal postings stay in Acumatica and are never sourced from Fishbowl.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Acumatica side it accepts the full instance URL and the exact endpoint version per customer, since a version mismatch returns 404, and it wraps every field value in the required value object so writes do not fail with a 400. On the Fishbowl side it accepts the customer's server URL and logs in with the app name, app ID, username, and password to obtain a Bearer token, re-logging in when a call returns an auth error since the token has no documented expiry. Because Fishbowl has no webhooks, both directions are polled: Acumatica is read on LastModifiedDateTime with a stored high-water mark, and Fishbowl purchase orders and inventory are polled at an interval suited to the on-premise server. Vendor and part codes are mapped first so each PO line references an item that already exists in Fishbowl. Acumatica has no idempotency header, so ml-connector checks for an existing record by natural key, such as the vendor reference on a bill, before creating, and re-posts under the same key to avoid duplicates. Both sides can return 429 under load, so it backs off with jitter. Many Fishbowl servers sit behind a firewall, so the connector supports a local polling agent inside the customer network when the API cannot be reached directly.

A real-world example

A mid-sized contract manufacturer with around 150 employees runs Acumatica Cloud ERP for purchasing, finance, and vendor management, and runs Fishbowl Advanced on a server in the plant for inventory and receiving. Before the integration, a buyer entered each purchase order twice, once in Acumatica for approval and again in Fishbowl so the warehouse could receive it, and a clerk later keyed received quantities back into Acumatica to release the vendor bill. The double entry caused mismatched quantities and late bill matching at month-end. With Acumatica and Fishbowl connected, approved POs and their vendors and items flow into Fishbowl automatically, receipts flow back to settle the matching bill, and the duplicate keying is gone.

What you can do

• •Push Acumatica vendors and stock items into Fishbowl so the warehouse catalog matches purchasing.
• •Mirror approved Acumatica purchase orders into Fishbowl so receiving happens against the correct document.
• •Read Fishbowl goods receipts and inventory counts back to post or settle the matching Acumatica bill.
• •Bridge Acumatica OAuth and version-locked endpoints with Fishbowl's on-premise server URL and Bearer session token.
• •Poll both systems on a schedule, with natural-key dedup, retries, error replay, and a full audit trail on every record.

Questions

Which direction does data move between Acumatica and Fishbowl?

Both directions, with each system owning what it is built for. Vendors, items, and approved purchase orders move from Acumatica into Fishbowl, while goods receipts and inventory counts move from Fishbowl back into Acumatica to settle the matching bills. Fishbowl has no chart of accounts, so GL accounts and journal postings stay in Acumatica.

How does the integration reach Fishbowl when it runs on-premise?

Fishbowl Advanced runs on the customer's own server at a host and port they control, so ml-connector takes the server URL as a credential rather than a fixed cloud address. It logs in with the app name, app ID, username, and password to get a Bearer token. When the server sits behind a firewall, a local polling agent inside the customer network can reach Fishbowl and forward data to the platform.

How does the integration handle Acumatica's version-locked URL and lack of webhooks on Fishbowl?

ml-connector accepts the full Acumatica instance URL and the exact endpoint version per customer, since a version mismatch returns a 404, and it wraps every field value in the value object Acumatica requires. Because Fishbowl has no outbound webhooks, both systems are polled on a schedule, with Acumatica read on LastModifiedDateTime and a stored high-water mark so only changed records are pulled.