Deltek and ShipBob integration

What moves between them

The flow runs from ShipBob into Deltek. ml-connector reads ShipBob billing invoices and the fee transactions on each one, then posts the fulfillment charges into Deltek as AP invoices against the ShipBob firm, with each line mapped to the matching Deltek GL account and, where the brand wants it, a project. ShipBob fee types such as pick and pack, storage, and shipping are aligned to Deltek GL accounts so every posted line lands on a valid account, and a billing.charge.created webhook can trigger the work as soon as a charge is raised. ShipBob shipment tracking and on-hand inventory are read for reference and reconciliation. ShipBob owns the physical fulfillment and its own billing, so ml-connector treats Deltek as the accounting destination and never writes invoices or financial entries back into ShipBob.

How ml-connector handles it

ml-connector stores both credential sets encrypted and runs two separate auth paths. On the ShipBob side it holds the OAuth 2.0 token, refreshes it on the one-hour expiry and rotates the 30-day refresh token, and attaches the shipbob_channel_id header to every call so reads stay uniform and any write is accepted. On the Deltek side it runs the OAuth2 password grant against the customer's tenant URL and refreshes the bearer token when a call returns 401. ShipBob fee types map to Deltek GL accounts and the ShipBob account maps to a single Deltek firm, and these maps are built first so every posted line references an account and a firm that already exists. Two real gotchas shape the flow: Deltek has no idempotency key, so the connector queries Deltek by invoice number and the ShipBob invoice id before writing to avoid duplicates; and the Deltek API user role must have full field visibility or amounts can come back as zero. ShipBob pages with a next-page header rather than a cursor, so the connector follows that header to read every invoice and transaction. A billing.charge.created webhook, verified by recomputing the HMAC-SHA256 over the webhook id, timestamp, and raw body, can trigger a run, while a scheduled poll on the billing invoices endpoint backfills anything a webhook missed. Every record carries a full audit trail and can be replayed if a Deltek post fails.

A real-world example

A direct-to-consumer brand doing a few thousand orders a month outsources warehousing to ShipBob across two fulfillment centers, while its finance team runs the books in Deltek Vantagepoint and tracks margin by product line as a project. Before the integration, an accountant downloaded the ShipBob invoice each cycle, split the pick and pack, storage, and shipping fees by hand, and keyed the totals into Deltek as a vendor bill, then spent month-end close reconciling the ShipBob charges against the ledger. With Deltek and ShipBob connected, each ShipBob billing invoice posts into Deltek as an AP invoice on the ShipBob firm, split across the right GL accounts and project, and the manual download and re-keying step is gone. Close starts from fulfillment costs that already tie out.

What you can do

• •Post ShipBob billing invoices into Deltek as AP invoices against the ShipBob firm, coded to the right GL accounts.
• •Split ShipBob pick and pack, storage, and shipping fees across Deltek GL accounts and an optional project.
• •Read ShipBob shipment tracking and on-hand inventory for reference and reconciliation against the ledger.
• •Receive ShipBob billing webhooks, verified by HMAC-SHA256, so a fulfillment charge posts soon after it is raised.
• •Bridge the ShipBob OAuth token and shipbob_channel_id header with the Deltek tenant login, with by-number dedup, retries, and a full audit trail.

Questions

Which direction does data move between Deltek and ShipBob?

The flow runs from ShipBob into Deltek. ShipBob billing invoices and their fee transactions move from ShipBob into Deltek as AP invoices against the ShipBob firm, while ShipBob shipment tracking and inventory are read for reference. ShipBob owns the fulfillment and its own billing, so ml-connector treats Deltek as the accounting destination and does not write entries back into ShipBob.

Why does the integration sync ShipBob billing rather than sales orders into Deltek?

Deltek Vantagepoint is a project services and government contracting ERP, so it has no documented inventory or sales-order resource to push fulfillment orders into. What it does have is AP invoices and a general ledger. ShipBob is a fulfillment vendor that charges the merchant, so the grounded sync posts ShipBob billing invoices into Deltek as vendor bills coded to GL accounts and projects. Order capture and inventory stay in ShipBob and the merchant's storefront.

How does the integration prevent duplicate postings into Deltek?

Deltek has no native idempotency key, so the connector checks each record before writing. It queries Deltek by invoice number and the ShipBob invoice id, creates the AP invoice only when no match exists, and keys its own job dedup to that ShipBob id. A scheduled poll on the ShipBob billing invoices endpoint catches any charge a webhook missed without re-posting work that already landed.