Microsoft Dynamics GP and Adobe Commerce integration

What moves between them

Item and customer master data flows from Microsoft Dynamics GP into Adobe Commerce. ml-connector polls GP inventory items and customers by ModifiedDate and upserts them into the Commerce product catalog and customer list so the storefront reflects current pricing, descriptions, and account records. Sales flow the other direction: placed orders and captured invoices move from Adobe Commerce into Microsoft Dynamics GP as receivables invoices, mapped to the matching GP customer and inventory items. GP has no GL chart of accounts in Commerce and Commerce holds no AR ledger, so financial posting stays in GP. Master sync runs on a schedule; orders post as the webhook fires, with polling as a backstop.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Adobe Commerce side it signs each PaaS request with OAuth 1.0a or refreshes the IMS bearer token before its roughly 24-hour expiry, and verifies the synchronous webhook signature against the stored public key, returning quickly so a slow response never stalls a shopper's checkout. On the Microsoft Dynamics GP side it presents Windows credentials over the customer's exposed SBA REST endpoint, or through a local agent when the GP server is not reachable from the cloud, and accepts the full server and company URL per customer because GP publishes no shared base address. Because GP has no webhooks, item and customer reads are polled on ModifiedDate, with status and batch filters where a record carries no modified date. SBA writes wrap the body in a Payload key, and a receivables invoice only posts cleanly when its fiscal period is open and, on a multicurrency company, a CurrencyId and ExchangeRate are supplied. GP has no idempotency header, so a duplicate document number is rejected rather than silently duplicated; ml-connector dedups each order by its increment_id before posting. Polling is throttled to a few parallel calls so it does not slow GP for its own users. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized specialty distributor with about 80 staff sells industrial parts both through outside sales reps and a B2B web store. The store runs on Adobe Commerce and the back office runs on Microsoft Dynamics GP on a server in their own building. Before the integration, a clerk re-keyed each web order into GP receivables by hand and updated the storefront catalog from a spreadsheet exported out of GP, so prices drifted and stock that had already sold still showed as available. With Microsoft Dynamics GP and Adobe Commerce connected, item and customer changes flow out to the store on a schedule and every paid web order posts back into GP as a receivables invoice against the right customer. The clerk's re-keying disappears, the catalog stays current, and revenue lands in the ledger the same day.

What you can do

• •Push Microsoft Dynamics GP inventory items and prices into the Adobe Commerce product catalog on a schedule.
• •Sync Microsoft Dynamics GP customers to Adobe Commerce accounts so online buyers map to GP customer records.
• •Post Adobe Commerce orders and captured invoices back into Microsoft Dynamics GP as receivables invoices.
• •Bridge GP Windows Authentication over an exposed SBA endpoint or local agent with Adobe Commerce OAuth.
• •Verify webhook signatures and dedup each order by increment_id so it posts once.

Questions

Which direction does data move between Microsoft Dynamics GP and Adobe Commerce?

Item and customer master data moves from Microsoft Dynamics GP out to Adobe Commerce, and placed orders and captured invoices move from Adobe Commerce back into Microsoft Dynamics GP as receivables invoices. Master data is pushed to the storefront on a schedule, while orders post as the Commerce webhook fires. GP holds the AR ledger and Commerce has no GL resource, so financial posting stays in GP.

How does the connector reach an on-premises GP server?

Microsoft Dynamics GP has no cloud edition, so the customer either exposes their Service Based Architecture REST or SOAP port through the firewall with a valid certificate, or runs a local agent on their network that relays calls to the GP server. ml-connector authenticates with Windows credentials in either case, since GP supports no OAuth or API keys, and accepts the full server and company URL per customer.

How are duplicate orders avoided when posting into Microsoft Dynamics GP?

Adobe Commerce provides no idempotency key, and Microsoft Dynamics GP rejects a duplicate document number rather than silently creating a second record. ml-connector dedups each order by its increment_id before posting and re-enqueues failed work under the same job id, so a retried webhook never creates a duplicate receivables invoice in GP.