Moving from SellAuth | PaidGoods Docs

Open Settings → Import and pick SellAuth.

Connect. Enter your shop ID and an API key. Both are in SellAuth under Developers → API. The key needs read access, plus permission to edit customers if you move balances. It is used for this import only and deleted when the run ends. No key? Upload CSV exports instead (products, serials, groups, categories, customers, coupons, invoices).
Choose. We read the shop without changing anything and list what we found, with counts, all ticked, customer balances included. Serials, quantity deals and bundles need products; reviews need invoices; tickets and affiliates need customers.
Import. Products arrive hidden. The result lists what needs you, each with a link to the page that fixes it. Run it again right before you switch over to catch late orders and stock, then choose Make products visible.

What to expect:

Invoices are kept as read-only history. They don't count as sales, deliver anything or send email.
Customer balances become store credit here and are set to 0 on SellAuth, so they aren't counted twice. Untick Customer balances to leave them on SellAuth.
Themes are downloaded from SellAuth with the same key and added to Storefront → Themes. With Make my SellAuth theme active on (the default), the theme your SellAuth shop uses goes live here; the others stay inactive. SellAuth's built-in default theme has no code to copy. If a theme can't be downloaded, use Download zip in SellAuth's code editor and upload the ZIP on the Themes page.
Payment methods arrive switched off. Reconnect each provider before enabling it.
Not copied: downloadable files (SellAuth doesn't share the downloads), custom domains, and email contacts and lists. Newsletter subscribers come over unsubscribed. The field-by-field decisions are in docs/parity/SELLAUTH-IMPORT-COVERAGE.md.

The import sends no email, notifications or webhooks and issues no rewards.

PaidGoods exposes a SellAuth format under /formats/sellauth. Change a script's base URL to https://api.paidgoods.com/formats/sellauth and use a PaidGoods API key. Its SellAuth paths, such as /v1/shops/..., remain unchanged after that prefix. The public API reference lists the routes generated from the current OpenAPI file.

The aliases take SellAuth's paths and request fields (for example PUT /v1/shops/{shopId}/products/{productId}/update with variants[].price in major units, PUT .../stock/{variantId} with { "stock": 10 }, coupons with discount and type: percentage). What differs:

Ids are PaidGoods UUIDs, not SellAuth's integers. Send a variant's id on product update to keep that variant and its stock.
Responses are the native PaidGoods shapes. Lists use SellAuth's envelope: data, current_page, per_page, last_page, total.
GET /formats/sellauth/v1/user and GET /formats/sellauth/v1/shops take a store API key (sk_…).
The reseller and customer-dashboard aliases also need an X-Shop-Id header with the supplier store's id. Reseller invoices honour Idempotency-Key.

Known unsupported or partial families are tracked in docs/parity/SELLAUTH-DOCS-GAPS.md. The important 501-style gaps include dynamic reseller delivery, much of the customer-dashboard API beyond balance, exact bulk product/deliverable endpoints, many merchant /v1/shops families, custodial crypto wallet payout behavior, and exact endpoint-specific pagination/filter compatibility.

For embeds, change the script source to the PaidGoods store domain and keep using sellAuth.open, sellAuth.close, sellAuth.on, and sellAuth.off where possible. The PaidGoods script also supports the native StoreEmbed global.