Getting Started

Go to Sign up. You'll need:

• Email (required)
• Password (required, minimum 8 characters)
• Name (optional)

Or use Continue with Google to skip the password step entirely. The Google button only appears if the deployment's Supabase project actually has Google sign-in switched on — see §11 if you operate the deployment and want to enable it.

After signing up with email/password, check your inbox and confirm your email address before you can log in — the signup page shows a "check your email" screen as a reminder. If you signed up with Google, you're taken straight into the onboarding wizard.

Forgot your password? Use the "Forgot password?" link on the login page.

New accounts land in a short onboarding wizard rather than a bare "create business" form. You'll be asked for:

1. A short description of what your business sells or does.
2. Your website URL — WonderArk visits it and researches your business automatically (products, positioning, audience) to save you re-typing things you've already published.
3. A short description of your target audience.

WonderArk uses this to create your business, create your first offering, and run an initial AI analysis (ideal customer profile, etc.) so your Discovery dashboard isn't empty on day one. You don't need to name your business yourself in this step — a name is derived from your description and can be changed later.

This trips up new users, so it's worth explaining once:

• A business is your one shared operational back office: one inventory, one tax registration, one crew, one customer ledger — regardless of how many things you sell.
• A business offering (managed inside the Discovery module) is one product or service line you market — its own ideal customer profile, its own prospect list, its own AI usage. A single business can have several offerings (e.g. a hardware store that also does installation), each with its own Discovery pipeline, but they all still share the same Inventory stock, the same GST/tax registrations, and the same CRM customer records underneath.

In short: offerings are "what you sell," and they sit on top of a single shared business. Inventory, Service, CRM, and Finance all operate at the business level; only Discovery operates per-offering.

• The business switcher (top bar) lists every business on your account. Pin the ones you use most so they float to the top; there's always a "+ Create New Business" option at the bottom.
• The module selector (sidebar) switches between a business's licensed modules (Discovery / Inventory / Service / CRM / Finance). An unlicensed module still shows in the list, greyed out with a lock icon — clicking it explains that it isn't licensed yet rather than crashing. You can also "pin" to one module to keep the sidebar focused on just that module until you unpin it.

Go to Settings → Licenses. For each of your businesses you'll see every module with a status:

Buttons let you Activate a module, Cancel an active one (a confirm dialog explains the grace period before you commit), Reactivate during grace or after cancellation (this restores full access and replays anything that was queued up while you were on hold), or Undo cancellation while it's still pending.

Cancelling a module never deletes your data — worst case you get a 30-day read-only window, then the module is simply inaccessible until you reactivate.

Settings → Billing is account-wide (not per business):

• Connect your own AI provider key (OpenAI, Anthropic, or Google Gemini) so AI features run on your own account, or leave it on App Internal AI to use WonderArk's shared credits instead — no key required, capped by your plan's free-tier allowance.
• Buy AI credits if you're on App Internal AI and need more headroom.
• A pricing-tier comparison table for reference (Free is the only plan you can actually purchase today).

Settings → Usage shows your account-wide AI usage this month, remaining credit balance, and a breakdown per business/offering (each Discovery offering has its own separate free-tier allowance, so there's no single blended percentage across your account).

\<business\> → Admin → Team is the one shared place — across every module — where you see:

• Every member of the business and their role.
• The eight built-in roles (Owner, Admin, Inventory Manager, Procurement Manager, Sales Manager, Accountant, Warehouse Operator, Viewer) and, for each one, exactly which permissions it grants, grouped by module.

Today this page is read-only — it's where you check what a role can do, not yet where you invite people or reassign roles (custom roles and in-app role assignment are on the roadmap). Note that only Owner and Admin can touch module-configuration screens like CRM's channel connections or routing rules — operating roles like Sales Manager can work the pipeline but not reconfigure integrations.

\<business\> → Admin → API Keys manages keys for WonderArk's public REST API, which every licensed module exposes resources through. Generating and revoking keys requires the settings.manage permission (Owner/Admin by default).

If you operate a WonderArk deployment (rather than just using one), there is a separate staff-only control plane at /platform — global branding, plans, feature entitlements, usage limits, which modules exist at all, internal AI provider keys, and so on. It's not a licensable module and ordinary business admins never see it; it exists for whoever runs the WonderArk service itself.

If you're standing up your own instance, apps/web/.env.example documents every variable. Grouped by purpose:

None of this is needed by an ordinary business user signing up on an existing WonderArk deployment — it's only relevant to whoever operates the deployment itself.

The application code for Google sign-in is already in place — the "Continue with Google" button, the OAuth redirect, and the /auth/callback handler that turns Google's response into a session. What it needs is credentials, and those are configured outside the codebase, in two places. Until they exist the button is hidden rather than shown and broken, so enabling Google is a configuration change only: nothing to deploy, nothing to rebuild.

Step 1 — Create OAuth credentials in Google Cloud

1. Open the Google Cloud Console and select (or create) a project for this deployment.
2. APIs & Services → OAuth consent screen. Choose External unless every user will have an account in your own Google Workspace, then fill in the app name, a support email, and your logo. Add the scopes .../auth/userinfo.email, .../auth/userinfo.profile and openid — these are the defaults and are all WonderArk asks for. While the consent screen is in Testing, only the accounts you list as test users can sign in; Publish it before go-live.
3. APIs & Services → Credentials → Create credentials → OAuth client ID. Application type: Web application.
4. Under Authorised JavaScript origins, add the origins people will actually load the app from — e.g. https://your-domain.com and, for local work, http://localhost:3000.
5. Under Authorised redirect URIs, add one URI, and it is Supabase's, not your app's: `` https://<your-project-ref>.supabase.co/auth/v1/callback ` This is the single most common thing to get wrong. Google redirects to Supabase, and Supabase then redirects to WonderArk's own /auth/callback — so your own domain does not belong in this field. A mismatch here shows up as redirect_uri_mismatch` at sign-in time.
6. Copy the Client ID and Client secret.

Step 2 — Turn the provider on in Supabase

1. Open the Supabase dashboard for this deployment's project → Authentication → Providers → Google.
2. Toggle it Enabled, paste the Client ID and Client secret, and save.
3. Still in Authentication, check URL Configuration:
   • Site URL — your production origin (e.g. https://your-domain.com).
   • Redirect URLs — add https://your-domain.com/auth/callback, plus http://localhost:3000/auth/callback for local development and a wildcard for preview deployments if you use them (e.g. https://*-your-team.vercel.app/auth/callback). WonderArk always asks Supabase to send people back to {origin}/auth/callback, taking the origin from the request itself, so the same build works in local dev, previews and production — but every origin you want that to work from has to be on this allowlist.

That is the whole of it. Within five minutes (the button's cached view of the project's settings) — or immediately on the next cold start — the Google button appears on both the login and signup pages.

Checking it worked

curl -s -H "apikey: <your-publishable-key>" \
  https://<your-project-ref>.supabase.co/auth/v1/settings | grep google

"google": true means the provider is live. This is the same endpoint the login page itself asks, so if it says true, the button is showing.

What happens to someone who signs in with Google

They land on the same onboarding wizard an email signup does, with their Google display name and profile picture already filled in, and no password on the account. If they later want to sign in with a password instead, they can set one through Forgot password? on the login page — the reset email goes to the same address Google verified.