Acumatica eBay Integration — A Complete Guide

eBay has no native Acumatica connector, so every eBay integration is built on two things: eBay's Sell APIs (Inventory API for listings and stock, Fulfillment API for orders) on one side, and Acumatica's contract-based REST API on the other. There is no vendor package to install — the work is a middle layer that translates eBay's data shapes into Sales Orders, Shipments, and Stock Item updates, and it is almost entirely about handling the cases eBay's API documentation glosses over.

Order import is not a straight mapping

An eBay order pulled from the Fulfillment API does not map one field to one Acumatica field. Line items reference eBay listing IDs, not your internal Inventory ID, so the middle layer needs a mapping table (or a custom field on Stock Items holding the eBay listing ID) before it can build a Sales Order. Multi-item orders, partial cancellations, and buyer-initiated returns each need separate handling — a return does not undo the original order, it needs its own RMA or credit flow on the Acumatica side, and treating it as "delete the sales order" corrupts your fulfilment history.

public class SOOrderEntry_EbayExt : PXGraphExtension
{
    public PXAction importFromEbay;
    [PXUIField(DisplayName = "Import from eBay")]
    [PXButton]
    protected virtual IEnumerable ImportFromEbay(PXAdapter adapter)
    {
        // Poll Fulfillment API for orders since last checkpoint,
        // map eBay listingId -> InventoryID via UsrEbayListingID,
        // then create/update SOOrder through the standard graph API
        // instead of writing directly to the DAC.
        return adapter.Get();
    }
}

Inventory sync is the part that actually breaks

Pushing stock levels to eBay is simple until you have the same SKU listed on eBay, Amazon, and your own storefront simultaneously. A sale on any channel needs to decrement available quantity everywhere else within seconds, or you oversell — and eBay's seller performance metrics penalize sellers who cancel orders for out-of-stock items. The reliable pattern is a single source of truth for available-to-sell quantity (computed in Acumatica from on-hand minus allocated minus a safety buffer) pushed out to every channel on a short interval, rather than each channel computing its own view of stock.

Fees and the accounting side

eBay deducts final value fees, payment processing fees, and promoted listing fees before payout, and the payout total rarely matches the sum of order totals. Booking eBay revenue as a single lump payout without recording the fee breakdown makes reconciliation in AR effectively impossible. Pull the transaction-level fee report from eBay's Finances API and post fees as a separate AP-side deduction or a contra-revenue line, tied to the same order reference used on the Sales Order — that is what makes the monthly reconciliation an actual match instead of a guess.

Rate limits and token refresh

eBay's OAuth tokens expire in about two hours and require a refresh token exchange, and the Sell APIs enforce per-application call limits that vary by endpoint. A sync job that fails silently on an expired token stops importing orders without raising an obvious error — build the refresh into the same scheduled process that imports orders, and alert on API error responses rather than only on total sync failure, since a partial failure (some orders imported, some silently skipped) is the failure mode that costs the most in missed shipments.

Wrapping up

There's no packaged Acumatica-to-eBay connector because the mapping problem — listing IDs to inventory items, multi-channel stock reconciliation, fee-level accounting — is specific enough to each seller's catalog that a generic connector either does too little or hides the parts you actually need to control. Build the order import and inventory push as an explicit middle layer on the contract-based REST API, poll for reconciliation instead of trusting webhooks alone, and post eBay fees at the transaction level so AR reconciliation isn't a monthly guessing exercise.