Shopify B2B & the wholesale channel
The B2B API is the programmatic version of the trade admin: companies, locations, contacts, catalogs, price lists and draft orders can all be created and updated by code rather than by hand. For a brand with a warehouse system or an accounting package that already holds this data, that is the difference between one source of truth and two.
For most brands with a dozen stockists, it is also the wrong project. The honest test is whether you are typing the same information into two systems often enough that the typing costs more than the integration would. Below that line, the admin is faster than any code you would write.
What the API can actually touch
Five areas matter for a wholesale brand.
Companies and locations. Create a company, add its locations, attach contacts, and set which catalog and payment terms each location gets. This is the record that makes a chain with four shops behave like one account, which is described in company profiles.
Catalogs and price lists. Attach a catalog to a company, populate a price list with fixed prices, and update those prices in bulk. This is the single most useful thing to automate, because price lists are the thing that goes stale fastest and hurts most when it does.
Draft orders. Build an order programmatically with the right prices, then send it to the buyer to approve and pay. Useful when orders arrive in a structured form from somewhere else, such as a rep's tablet or a spreadsheet from a chain.
Orders and fulfilment. Read trade orders out, push tracking back in. Standard integration work, and the same as for consumer orders except that trade orders are wider and freight is often handled separately.
Customer and contact permissions. Who at a company can order, and on whose behalf. Rarely worth automating below a few dozen accounts.
The four integrations worth building
In rough order of payback for a small brand.
Price list sync from your own source of truth. If your prices live in a spreadsheet or an accounting system, pushing them into price lists on a schedule removes the most dangerous manual step in wholesale, which is a price that is right in one place and wrong in another. A buyer paying last year's price on a product whose cost rose is a quiet, recurring loss.
Inventory sync from a warehouse or third-party logistics system. Trade orders are large, so overselling hurts more than it does on the consumer side. One case oversold is a phone call and a partial shipment.
Order push into accounting. Trade orders come with invoices, due dates and, sometimes, partial payments. Getting them into the books automatically saves the reconciliation hour that everyone hates and everyone postpones.
Company creation from your application form. Only worth it if applications arrive in real volume. Two minutes by hand, twenty times a year, is not a problem worth writing code for.
Notice what is not on the list: building a custom trade storefront. Brands reach for that early and regret it, because the storefront is the part that needs maintenance forever and the part buyers care about least.
What it costs to own an integration
An integration is not a project, it is a commitment, and the cost lands mostly after launch.
There is the build itself, which for a focused price list sync is days rather than weeks in competent hands. There is the hosting, because something has to run on a schedule. There is authentication and permissions, which need looking after. And there is the API version cycle: platform APIs move, and an integration nobody updates will fail, usually at the worst moment, which is a seasonal ordering peak.
Then there is the part brands underestimate: error handling. What happens when a price update refers to a product that no longer exists, or a company has two locations with the same name, or a draft order includes a product the buyer's catalog does not contain. Every one of those happens in the first year, and an integration that fails silently is worse than no integration at all, because you stop checking.
A reasonable rule is not to own an integration unless someone, internally or on retainer, can look at it within a day when it breaks.
Buy before you build
Most of what a small brand wants from the API is already sold as software. Price sync, order forms, rep tools, terms and invoicing all have established products, and the categories are laid out in the five B2B app categories.
Buying wins on three grounds. Someone else tracks the API changes. The cost is a predictable monthly number rather than an unpredictable developer week. And when it breaks, there is support rather than a search through your own logs.
Build wins in exactly two cases. Your process is genuinely unusual, usually because of how your products are configured or how your industry handles freight and returns. Or the system you need to connect to is one nobody has built an integration for, typically an older warehouse or accounting package.
The middle path that works well for a lot of brands is a small, single-purpose script rather than a platform: one job, one schedule, one notification when it fails. Fifty lines that sync prices beats a framework that does nine things you do not need.
Sequence it behind the things that matter
An API integration is the last thing a wholesale channel needs, not the first. The order that produces revenue is: a price you can defend, a line sheet, terms in writing, the first ten accounts, a way for them to reorder without an email thread, and only then automation of whatever you have been doing by hand.
A brand that inverts this ends up with a beautifully synced system holding four accounts. The features themselves are described in what the native B2B tools do, and the manual version of order building, which most brands should run for a year first, is in draft orders for wholesale.
If the constraint is that you do not have enough accounts to justify any of this, that is the problem to work on. Paste a product link into WholesalePilot and look at the preview of retailers and distributors that stock comparable products, and build the list before you build the plumbing.
A worked example of when it tips
Take a brand with thirty stockists, two hundred trade orders a year, and prices held in a spreadsheet because that is where the cost calculations live.
Before automation, every price change is a manual update in two places, done twice a year across ninety products, which is a careful afternoon each time and a real chance of an error that survives for months. Every order is checked against stock by eye, and roughly once a season something oversells. Every month, trade invoices are typed into the accounts.
Put numbers on that: eight hours a year on prices, a couple of hours a month on accounting, and an oversell or two that costs goodwill rather than money. Call it thirty to forty hours a year plus the errors.
A price sync and an order push, built once, remove most of it. At that volume the integration pays back inside a year and keeps paying. At six stockists and thirty orders, the same integration removes four hours a year and adds a thing that can break, which is a bad trade in both directions.
Questions brands ask about the B2B API
Does using the API require the top plan? The trade objects it manipulates exist on the plan that includes native B2B, so the integration follows the plan rather than replacing it.
Can you create a company and a price list in one go? They are separate objects with a relationship, so the sequence is create the company, create or select the catalog, attach the price list, then attach the company to the catalog. Getting that order wrong is the most common first mistake.
Is it possible to give each account its own prices? Yes, by attaching a different catalog per company, which is the mechanism behind per-account pricing generally.
Can a rep place orders on behalf of a buyer? Draft orders handle this well: the rep builds it, the buyer approves and pays. It is also the pattern for orders taken at a trade show.
What is the smallest useful integration? A scheduled price list update from wherever your prices actually live. It takes the least code and removes the error that costs the most.