For Shopify agencies
How to evaluate a Shopify B2B app: questions for agencies and solution architects
By Jahangir Alam · September 20, 2026 · 15 min read
- Last verified
- Shopify API
- 2026-07
- Audience
- Shopify agencies, developers and solution architects vetting a B2B app for a client
- Scope
- Any Shopify B2B, quote, pricing or buyer-portal app; the Shopify mechanisms an answer can be checked against
A Shopify B2B app is safe to put in front of a client when it uses Shopify's own objects - Companies, locations, catalogs, draft orders - instead of parallel ones; extends the storefront and the customer account through extensions rather than injected code; keeps only the data it needs and erases it on Shopify's mandatory webhooks; targets a supported GraphQL API version and handles throttling and webhook retries; and can prove each of those answers rather than assert them. The 53 questions below are grouped so an agency can work through them in an afternoon, and each one comes with the way to verify the answer yourself, because a vendor page says yes to everything.
This checklist is vendor-neutral. It applies to a request-a-quote app, a wholesale pricing app, a buyer-portal app or a custom build, and it was written by a vendor whose own answers are published separately, linked at the end. Use it before the trial, not after: most of the questions can be answered from documentation, a development store and a browser's network tab, and the ones that can't are the ones to put in writing.
How to run the evaluation
- Answer from the documentation first. An app that has documented its data retention, its API version and its uninstall behaviour has thought about them; one that hasn't will answer from memory in a sales call.
- Install on a development store. Development stores are free and B2B-capable, and app subscriptions on them are test charges, so every "does it actually" question below can be checked without the client's store. Set up two companies, three locations, two catalogs with an overlapping product, one location on Net 30 and one on draft-only checkout.
- Put the remaining questions in writing and keep the answers with the project. The answer to "what is erased on uninstall" is part of the client's data-processing record, not a chat message.
A. Native fit
The single most expensive mistake is an app that recreates something Shopify already owns. What lives in Shopify and what belongs in the quote layer is the reasoning; these are the questions.
| Question | Why it matters | How to verify |
|---|---|---|
| Does it use Shopify Companies, company locations and company contacts as its customer model, or its own "accounts"? | Catalogs, payment terms, tax exemptions and checkout settings all hang off the Shopify location; a parallel account model duplicates every one of them | Create a company in Shopify admin and check the app shows it without re-entry; look for company and location IDs in the app's records or exports |
| Does it read the location's catalog price rather than keeping a price list? | A location can have several catalogs and Shopify shows the lowest; volume pricing fixes a price and removes the catalog's percentage adjustment. A copy cannot know either | Give a test product two catalog prices for one location, then check the price the app starts from; ask whether pricing is resolved through contextualPricing at request time |
| Does an accepted quote become a native draft order for the company, with the buyer's location and contact on it? | A draft order created with a purchasingEntity picks up the location's terms and checkout settings; one created for the person does not |
Convert a test quote and open the draft order in admin: company, location and contact should be on it, not just a customer |
| Does the agreed price reach the draft order line, or does the app add a discount to fake it? | A negotiated unit price belongs in priceOverride on the line; a discount code changes reporting and can be removed |
Convert a quote with a negotiated price and read the draft order: line price versus applied discounts |
| Does it apply the location's Shopify payment terms, or run its own? | Terms are collected by Shopify; an app's own "net terms" is a second receivables system | Check the converted draft order's payment terms against the location's setting |
| Does it work on Basic, Grow and Advanced, or does it check for Plus? | B2B has been on every plan since 2 April 2026; an app gating on the plan name rather than the capability is out of date | Install on a non-Plus development store with B2B enabled and try company-aware features |
| Does it offer deposits only where Shopify does? | Deposits are a Plus feature (DraftOrderInput.deposit); an app promising deposits on a Basic store is promising something Shopify cannot collect |
Ask where the deposit is collected; the only correct answer is Shopify checkout on the draft order, and only on Plus |
| Is product eligibility - which products can be quoted, at what quantity - enforced on the server, or only hidden in the storefront? | A hidden button is not a rule; a buyer with a URL can submit anything | Submit a request for an excluded product by editing the form request in the browser's network tab; the server should reject it |
| Can a line that is not a variant - a custom size, a service, a setup charge - be added with its own price, tax flag and shipping flag, and does it reach the draft order as a custom line? | Real quotes have lines the catalog doesn't; a draft order supports custom lines with exactly those flags | Add one in a test proposal and convert; check the draft order line has no variant and carries the flags |
B. Storefront
| Question | Why it matters | How to verify |
|---|---|---|
| Is the storefront integration a theme app extension - app blocks in sections, app embed blocks for overlays - or code injected into the theme's files? | Extensions are added and removed by the merchant in the theme editor and leave nothing behind; injected code has to be cleaned out by hand and breaks on theme changes | In the theme editor, look under Apps in a section and under Theme settings > App embeds; then search the theme's Liquid files for the app's name |
| Is the app embed activated after install, and does the merchant know? | App embed blocks are "deactivated after an app is installed" and must be switched on in the theme editor; an app that reads as broken on day one is usually this | Install and check Theme settings > App embeds before touching anything |
| What does it load on every page, and how heavy is it? | Shopify's suggested limits for a theme app extension are 10 KB of compressed JavaScript and 100 KB of CSS; Built for Shopify requires that an app "must not reduce the storefront Lighthouse performance score by more than ten points" | Open a product page with the network tab filtered to the app's domain; run Lighthouse with the app embed on and off |
| Does it survive a theme update or a switch to a new theme? | App blocks are placed per section, so a new theme starts without them; app embeds are switched on per theme in the theme editor. Anything injected into theme files does not come across at all | Duplicate the theme, publish the copy, and check what still works; then try a fresh theme |
| What happens on a headless storefront? | Theme app extensions are Liquid rendered by the Online Store; a Hydrogen or custom storefront renders none of them. Headless B2B works through the Storefront API contextualised with the buyer's token and companyLocationId, so the app needs an API or component path of its own |
Ask for the headless integration guide; if the answer is "our app block", there isn't one |
| Does the request path work without JavaScript, and is it accessible? | A quote request is a form; a form that only exists in JavaScript fails for assistive technology and for a blocked script | Submit a request with JavaScript disabled; run an accessibility check on the form |
| If it hides prices, which layer? | A visual hide swaps the price element for a button and leaves the number in the page source, meta tags and structured data; a search-engine-safe hide keeps it out of the HTML a signed-out visitor receives, and that needs a one-time theme edit because an app cannot remove the theme's own markup | View source on a product page as a signed-out visitor and search for the price; ask how the app verifies the hide |
C. Customer accounts and the buyer
| Question | Why it matters | How to verify |
|---|---|---|
| Does it require the current customer accounts, and what does it do on a store that hasn't activated them? | Legacy customer accounts were deprecated on 26 February 2026 and never supported B2B; the buyer experience now lives in the current accounts or in a hosted page the app provides | Ask what a store without customer accounts activated gets; the honest answers are "a hosted portal" or "nothing" |
| Is the in-account experience a customer account UI extension? | Extensions run inside Shopify's account (order index, order status, profile, full page) under Shopify's login, with a 64 KB bundle limit (128 KB for a full page); anything else is a link out | Sign in as a test buyer and see whether the app's page is inside the account or on another domain |
| What does a guest get? | Native B2B shows prices only to a contact assigned to a location; buyers who ask before they have an account are the top of the funnel | Request a quote signed out; check how the buyer is reached and whether the quote attaches to a customer once one exists |
| Does it understand a buyer on several locations? | A contact with three locations chooses one before checkout; a quote has to belong to a location, not to the person | Give a test contact two locations and request quotes from each |
| Can the buyer see their quote and order history in one place? | Buyers re-order from history; an app that keeps history somewhere the buyer never goes is invisible | Check the buyer's account page after conversion for both the quote and the resulting order |
D. Data, privacy and lifecycle
| Question | Why it matters | How to verify |
|---|---|---|
| Which data does it store, and in which region? | Name, address, email and phone are protected customer data; where they sit is a contractual question for the client | Read the privacy policy and the sub-processor list; ask for the region |
| Has it been approved for protected customer data, and at which level? | Shopify reviews public apps before granting access; Level 2 (name, address, phone, email) requires encrypted backups, separated environments, access logging and an incident-response policy | Ask for the Partner Dashboard access status and the level; an app that doesn't know hasn't done it |
| What is the retention policy, and can the merchant change it? | Attachments and generated documents accumulate; a retention window is a data-protection control, not a storage cost | Read the retention docs; check whether files are deleted on a schedule |
| Can the merchant export everything? | The client will leave one day; quotes, versions and approvals should leave with them | Run the export on the dev store and open it |
What is erased when shop/redact arrives, and when? |
Shopify sends shop/redact 48 hours after uninstall and the app must erase the store's data; some apps keep a recovery window first |
Ask for the exact behaviour and the window; it should match the docs |
How does it handle customers/redact and customers/data_request? |
The redact webhook arrives 10 days after a deletion request, or once six months have passed since the customer's last order; the app has 30 days to act. Every App Store app must implement all three | Ask what is redacted on a customer erasure and what a data request returns |
| Are uploaded files validated? | A quote attachment is an upload from an unauthenticated buyer | Ask what is checked; type and active-content validation is the honest answer, and a claim of malware scanning should come with the name of the scanner |
| Is there a DPA and a sub-processor list? | The client's own privacy notice has to name them | Ask for both before the contract |
E. API and reliability
| Question | Why it matters | How to verify |
|---|---|---|
| GraphQL Admin API, or legacy REST? | The REST Admin API "is a legacy API as of October 1, 2024" and since 1 April 2025 new public apps must be GraphQL only; newer B2B fields ship in GraphQL first | Ask which API the app uses today, not which it plans to |
| Which API version is it pinned to, and how does it upgrade? | Shopify releases a version every quarter and supports each for at least 12 months; an unsupported version "falls forward" silently. The app should name its version and its upgrade cadence | Ask for the current version; check it against the supported list on 20 September 2026: 2025-10, 2026-01, 2026-04, 2026-07 |
| How does it behave when throttled? | The Admin API allows 100 points per second on Standard, 200 on Advanced, 1,000 on Plus and 2,000 on Commerce Components, with a 1,000-point cap per query and a 429 when the bucket is empty; a bulk operation that ignores throttleStatus fails the whole store's other apps too |
Ask how bulk actions and syncs back off; look for throttleStatus-aware retry in the answer |
| Which webhooks does it depend on, and what happens when one is missed? | Shopify retries a failed delivery "8 times over the next 4 hours" and then deletes the subscription; delivery "isn't always guaranteed". An app that only learns about paid orders from orders/create will one day miss one |
Ask whether there is a reconciliation job that periodically fetches from Shopify, as Shopify's own guidance recommends |
| Are webhook deliveries verified and de-duplicated? | HMAC verification and ignoring repeats by X-Shopify-Webhook-Id are the baseline; a duplicate orders/create handled twice can mark a quote paid twice |
Ask directly; it is a yes/no with a header name in it |
| Is quote-to-order conversion idempotent? | A retried request or a second worker can create two draft orders for one acceptance; the fix is an idempotency key per conversion and a claim before draftOrderCreate |
Trigger a conversion twice in quick succession on the dev store and count the draft orders |
| Is the admin UI embedded with the latest App Bridge and session tokens? | Shopify requires session tokens for embedded apps and asks developers to "avoid third-party cookies or local storage"; Built for Shopify requires the latest App Bridge | Open the app in an incognito window with third-party cookies blocked |
| Which access scopes does it request, and why each? | App Store requirement 3.2 is to request only necessary scopes; write_orders and read_all_orders need a reason |
Read the scope list on the install screen and ask for the reason per scope |
| How does the client integrate with it? Shopify Flow triggers and actions, an API of its own, outbound webhooks - and what exactly does each expose? | The ERP and CRM questions are answered here; "we have Flow" means nothing without the list of triggers and their fields | Ask for the reference page listing every trigger, action and field |
| If it has checkout or customer-account extensions, what is their latency? | Built for Shopify requires checkout requests to have a p95 of 500 ms or less | Ask for the number; it is measured, not estimated |
F. Operations
| Question | Why it matters | How to verify |
|---|---|---|
| Can a rep send a price that needs approval without getting it? | "Approval required" that is a reminder in the interface is not a control; the check has to run on the server in the send path so an automation cannot skip it either | Configure a policy on the dev store and try to send from a rep account; then try through any automation the app offers |
| Can a rep approve their own quote? | Segregation of duties is the first thing an auditor asks | Make the rep an approver and test |
| Are approver limits and escalation expressible? | "Up to 10 percent, then a manager" is the common policy | Configure it; if the app can't, that is the answer |
| Does the accept link stop working when the quote expires? | An expired proposal that can still be accepted is a pricing hole | Set a one-day expiry on the dev store and try the link the next day |
| Are proposals versioned and immutable once sent? | The document the buyer received is a commercial record; an app that edits a sent proposal in place cannot say what was agreed | Send, then try to edit; the app should force a new version or a counter |
| Is there an audit log with actor and timestamp for every state change? | "Who approved this price" a year later | Perform five actions as two users and read the log |
| How do roles map to Shopify staff? | Shopify's sales-staff permissions scope which company records a rep sees; the app's roles decide what they may do to a quote; the two should compose, not conflict | Restrict a Shopify staff member to one location and check what the app shows them |
| What is on the documents? | PO number, terms, expiry, per-line prices, the version number; a signature block if the client needs one | Generate the PDF on the dev store and check the fields against the client's requirements |
| Can a buyer accept some lines and leave the rest open, and what does the order contain then? | Multi-line deals rarely close whole | Accept two of four lines in a test and read the draft order |
| What is the support model? | Hours, channel, response target, a status page, and whether the developer's emergency contact is current | Read the listing and ask |
G. Commercial
| Question | Why it matters | How to verify |
|---|---|---|
| Which features sit on which plan, and does the gating follow Shopify's capability or the plan name? | The client's plan and the app's plan are two different gates; both should be explicit | Read the pricing page; then check on a non-Plus B2B dev store |
| Is it Built for Shopify, and do you know what that proves? | The badge requires the storefront performance rule above, admin Web Vitals at p75 (LCP 2.5 s, CLS 0.1, INP 200 ms), a minimum of 50 net installs from active shops on paid plans, at least five reviews, and the latest App Bridge. It proves engineering hygiene and some adoption; it does not evaluate the B2B feature set | Check the badge on the listing; then run the rest of this list anyway |
| Can the whole build be proved on a development store before the client pays? | An agency build takes longer than a live-store trial | Ask whether the paid features run on a dev store |
| What do you get back when you leave? | Export format, whether draft orders and orders stay (they should - they are Shopify's), and what the app keeps | Run the export; read the uninstall doc |
FAQ
What does Built for Shopify actually guarantee?
Three measurable things and one adoption threshold: the app does not reduce the storefront Lighthouse score by more than ten points, its admin pages meet Web Vitals at the 75th percentile, its checkout requests (if any) have a p95 under 500 ms, and it has at least 50 net installs on paid plans and five reviews. It does not check whether the app uses Companies, reads catalog prices, enforces approvals or erases data properly. Treat it as a filter, not a verdict.
Should we disqualify an app that injects code into the theme?
For a new build, yes, unless there is a specific reason the extension model cannot do the job. Theme app extensions are added and removed by the merchant in the theme editor; injected code has to be found and removed by hand, breaks when the theme changes, and is usually the reason an app "doesn't work" after a theme update.
Does the app need Shopify Plus?
Only for what Shopify itself gates on Plus: unlimited catalogs, direct catalog assignment, deposits and partial payments. Companies, locations, catalogs, quantity rules, volume pricing, payment terms and draft orders are on every plan since 2 April 2026, so an app that requires Plus for company-aware quoting is checking the plan name rather than the capability. The plan matrix has the full list.
How do we verify "enforced server-side" without reading the code?
Try to do the thing the rule forbids from a client that isn't the app's interface. Submit a request for an excluded product by replaying the form request in the browser's network tab with a different product ID; send a proposal that needs approval from a rep account; accept an expired quote's link. If the server rejects each, the rule is real. The pattern generalises to every "can X bypass Y" question on this list.
What about the app's own API?
An app without an API of its own is not disqualified; most integration needs are met by Shopify Flow triggers and actions plus the Shopify order the conversion produces. What matters is that the vendor says which it is, lists what the triggers expose, and does not describe a roadmap as a feature.
Where are QuotWay's answers?
Published rather than printed here, so this list stays usable for any app: what QuotWay can and cannot do answers the feature and enforcement questions plan by plan, and security and data protection answers the data, retention and webhook ones; the B2B feature page and pricing cover the native-fit and plan-gating rows. Run the list against them the way you would against anyone else's.
Sources
Shopify pages, all read on 20 September 2026:
- Theme app extensions and theme app extension configuration and limits
- Built for Shopify requirements
- Protected customer data
- Privacy law compliance - mandatory webhooks
- GraphQL Admin API rate limits and API versioning
- REST Admin API reference - legacy notice
- Webhooks - verify deliveries, timeouts and retries and webhooks overview and best practices
- Customer account UI extensions
- Headless with B2B
- App Store best practices (requirements checklist)
- Draft orders for B2B, DraftOrderLineItemInput and ProductVariant.contextualPricing
- Customer accounts for apps and B2B for all
Related articles
See how QuotWay handles this on your store.