DEV Community

Geminate Solutions
Geminate Solutions

Posted on

Shopify App Creation: Embedded Admin App or Standalone Dashboard?

For most Shopify app creation projects, build an embedded admin app if merchants and their staff will use it every day inside Shopify. Build a standalone dashboard only if your product has to serve people or sales channels that live outside Shopify.

That is the short answer. Picking between them is the easy part. The harder part is what the choice locks you into two years from now.

You might be a CTO with a working prototype, or a technical founder who has to decide this before the first sprint. Your team is asking whether to use App Bridge and session tokens or roll your own login. Someone on sales keeps mentioning Amazon and TikTok Shop. You want to make the call once.

How does an embedded Shopify app actually log people in?

It doesn't, in the usual sense. Shopify loads your app inside an iframe in the admin, and App Bridge hands your frontend a short-lived signed token for the current shop and user. Your backend checks that token and gets on with the request.

The token is a JWT signed with your app secret and it expires in about a minute. Your backend verifies the signature, reads which shop and which staff member it belongs to, then uses Shopify's token exchange to get an Admin API access token. You never store a password, never build a login screen and never depend on cookies. That last point matters because browsers block third-party cookies inside iframes, which is exactly why Shopify moved to session tokens.

What you give up is control. Your app's identity is Shopify's identity. If a user doesn't have a Shopify staff account on that store, they can't get in.

What does a standalone dashboard need that an embedded app does not?

A standalone dashboard still needs the Shopify OAuth install to get an offline access token for the store. On top of that, you own the whole login system.

That means a users table, password hashing, reset emails, multi-factor sign-in, invitations, roles, session expiry and a mapping of which users can see which stores. Each piece is a normal engineering task. Together they become a security surface you maintain forever, and the most common source of incidents in apps we review is homemade auth that skipped one of those pieces.

The upside is freedom. Anyone can be a user, on any domain, with any permission model you design.

What can staff do inside the Shopify admin compared with a separate login?

Inside the admin, staff work where they already work. The merchant controls access through Shopify's own staff settings, and your app can show up in context: an action on the order page, a block on a product, a link from the navigation.

Offboarding is the quiet win here. When the merchant removes a staff member in Shopify, that person loses access to your app too. With online access tokens, your API calls carry that user's permissions, so a staff member who can't edit products in Shopify can't edit them through you either.

A separate login flips all of that. Staff now have a second password, a second tab and a second place to be removed from when they leave. Adoption usually suffers because the tool feels like extra work.

But a separate login is the only clean way to give access to people who are not store staff. Think warehouse partners, external accountants, suppliers or a client's agency. If those people are your main users, embedded is the wrong shape.

What does it cost you to get this wrong?

The cost is rework, and it lands at the worst moment.

Teams that start standalone and later want App Store distribution find that Shopify's Built for Shopify program expects an embedded experience. That means rebuilding the UI with Polaris, swapping their login for session tokens and retesting every flow. Teams that start embedded and later need outside users find their data model assumes every user is a Shopify staff member, so adding a supplier portal turns into a migration.

There is a trust cost too. A merchant asked to create yet another account during install often uninstalls before finishing setup. And a rushed custom auth layer added late is where data leaks between stores tend to start.

How does each choice limit you if you add other sales channels?

An embedded app ties identity to Shopify. A standalone dashboard ties nothing, but gives a weaker Shopify experience.

Here is the failure mode to watch for early. Open your schema and look at what the main account record is keyed on. If it is the myshopify.com domain, you have coupled your whole product to one platform. The day a merchant wants to connect a WooCommerce store or an Amazon seller account, or a brand with no Shopify store at all wants to sign up, there is nowhere for them to live.

The fix costs almost nothing on day one. Model an organisation or account as its own entity, and treat each Shopify store as a connection that belongs to it. Do this even if you only ever ship an embedded app at first.

Who does not need to think hard about this?

If you are building a custom app for your own single store, used only by your own team, skip the debate. Generate an embedded app from the Shopify CLI template, use the built-in session token handling and spend your time on the feature itself. The channel question only matters for products sold to many merchants or used by people outside the store.

Which should you choose for Shopify app creation, and in what order?

Use these rules:

  • If every user is merchant staff and the work happens next to orders and products, build embedded.
  • If your key users are not Shopify staff, build standalone, or a hybrid with a standalone portal for them.
  • If you plan to list on the Shopify App Store, embedded is the expected default.
  • If other channels are on the roadmap within a year, build an embedded frontend on a channel-neutral backend.

For most products the hybrid wins, built in this order. First, the account model that separates organisations from store connections. Second, the embedded app on session tokens and token exchange. Third, a standalone portal later, with its own login, pointing at the same accounts and the same backend. Each step reuses the one before it instead of replacing it.

What should you ask your team or vendor before anyone writes code?

  • What is the account record keyed on? This tells you whether multichannel later means an extension or a rewrite.
  • How are session tokens verified on every request? Skipping signature or audience checks is a cross-store data leak waiting to happen.
  • What happens when a staff member is removed in Shopify? The answer should be automatic, not a support ticket.
  • How do the app/uninstalled and privacy webhooks clean up data? Shopify requires those privacy webhooks, and orphaned tokens are a liability.
  • Can a non-Shopify user be added later without a migration? If not, you have picked standalone or embedded forever without meaning to.

If you want a second opinion on your architecture before you commit, Geminate Solutions has shipped 50+ products and will review your plan or prototype for free, with an NDA before we talk and a reply within 24 hours. You can see how we approach this kind of build on our web app development page.

Top comments (0)