API keys and sign-in providers

Issue scoped API keys for integrations, let customers sign in with Google or Facebook, and see who changed what.

Settings → Authentication is where you hand out access to your store. It has two tabs, API Keys and OAuth Providers, plus an MCP connect button and an audit-log panel, both sitting in the toolbar of the API Keys tab.

API keys

An API key lets an outside system talk to your store: a script, a warehouse tool, an AI assistant, anything that isn't your storefront.

A brainerce_* key is a credential. Anyone holding it can do everything you granted it, from anywhere. Treat it like a password: never paste one into a public repo, a chat, or a browser bundle. Keys belong on servers.

Create a key

Go to Settings → Authentication → API Keys.
Click Create API Key.
Give it a name you'll recognise later, such as "Warehouse sync" rather than "key 2".
Choose its permissions.
Create it, then copy the key immediately.

The key is shown once. There is no way to see it again. If you lose it, Rotate it (below) to get a fresh secret without rebuilding the key.

Choosing permissions

Permissions are split read/write per area: Products, Orders, Customers, Inventory, Media, Cart, Checkout, Reviews, Metafields, and more. Each has its own description in the dialog.

Grant the narrowest set that does the job. A stock-level script needs Inventory: Read and Inventory: Write and nothing else. If that key leaks, the damage is bounded to stock numbers rather than your whole catalog and customer list.

The dialog does offer shortcuts: a read-only preset, group-level toggles, and a select-all. Select-all is convenient while you're experimenting; it is the wrong choice for a key you're about to deploy.

Rate limits and IP allowlists

Each key can carry:

A rate-limit override, in requests per minute for this key alone. It cannot exceed your plan's limit.
An IP allowlist, so only these addresses may use the key. If your integration runs from a fixed server, this is the single most effective thing you can do to make a leaked key useless.

Rotate a key (what to do if a key leaks)

Rotate is the right response to a key you pasted somewhere public, or one you have simply lost. Click Rotate on the key's row: Brainerce issues a new secret and keeps everything else about the key: its name, its permissions, its rate-limit tier and its IP allowlist. The old secret stops working, so you only have to swap the string in your integration instead of building a key from scratch and re-picking every permission.

The new secret is shown once, exactly like a new key. Copy it before you close the dialog.

Rotate, don't revoke, when the integration should keep running. Revoke when it should stop.

Revoke a key

Click Revoke on the key. It stops working immediately and cannot be undone, so anything still using it will start failing at once. Use Revoke when the integration is finished with. For a key that leaked but is still in use, Rotate (above) closes the hole without breaking it.

The OAuth Providers tab controls how your customers sign in to your storefront, with Google, Facebook, or GitHub instead of a password. This is separate from your own dashboard login and from API keys.

Connect a provider here, and your storefront can offer it as a sign-in button.

Google works with no setup at all: Brainerce runs a shared Google app, so every store can offer "Sign in with Google" from day one. Facebook and GitHub have no shared app, so those need your own credentials from the start.

The trade-off is whose name your shopper sees. When they pick a Google account, Google's screen reads "to continue to Brainerce", shows the Brainerce logo, and links to Brainerce's privacy policy and terms, not your store's. If that is fine for you, you are done; there is nothing on this tab to configure.

You can have that screen read "to continue to your store", with links to your privacy policy and terms instead of ours. It takes three things, and all three are required:

Your own Google OAuth client, with Brainerce's callback URL registered on it (next section).
Your branding filled in on your own domain: app name, logo, homepage, privacy policy, terms.
Brand verification completed and published in Google Cloud Console.

⚠️ Doing only steps 1 and 2 leaves you worse off than the shared app. Google will not display a name for an app it has not verified. It prints the bare text brainerce.com instead, with no logo, and tells your shopper to review "brainerce.com's" privacy policy. That is Google's rule, not a Brainerce setting, and nothing on this tab changes it. Finish the verification and the screen switches to your store's name.

Your homepage, privacy policy and terms must be real, reachable pages on the domain you verify, because Google checks them.

Adding your own credentials also gives you your own rate quota, your own Google Cloud project for the sign-in logs, and the option to restrict sign-in to a single Google Workspace domain.

Whichever route you take, if you connect your own Google credentials this step is not optional. Google rejects any sign-in whose return address it hasn't been told about, and the error your shoppers hit is redirect_uri_mismatch.

On the built-in Google card, click Use your own credentials.
In Google Cloud Console, create an OAuth client of type Web application.
Under Authorized redirect URIs, add this address exactly:
```
https://api.brainerce.com/api/oauth/customer/callback
```
This address is identical for every Brainerce store. It is not your store's domain, and there is no per-store version of it. Putting your own domain here is the single most common way to break sign-in.
Copy the Client ID and Client Secret from Google, paste them into the dialog, and save.

Keeping Brainerce's callback URL here does not stop you showing your own store's name: the name comes from your verified branding, not from the callback address.

Your credentials take over immediately, and you don't need to disable the built-in provider first. The built-in card disappears from the list once your own credentials are active; delete them to fall back to the shared Brainerce app.

Facebook and GitHub use the same "add credentials" flow. Find them under Available to connect below the connected providers.

Google button missing from the storefront, or "redirectUrl is not allowed for this sales channel"

Turning a provider on here is half of it. The storefront also has to be an address Brainerce may return a signed-in customer to, and that is recorded on the sales channel, not on this tab. On a Test channel with an empty Domains box, the shop's catalog and checkout work from any address, including a Lovable or Bolt preview, but a Google sign-in cannot return to an address that was never recorded, so the storefront hides the button there (an older storefront shows the redirectUrl is not allowed message instead). localhost is the one exception and always works on a Test channel.

Fix: Sales Channels → your channel → General → Domains, add the address the storefront runs on, save. Full walkthrough: Sign in with Google fails on a Test channel with no domain. This is unrelated to redirect_uri_mismatch, which comes from Google and means the callback URL above is missing from your Google client.

Webhooks go the other direction: your store notifying an outside system.
Connect an AI assistant covers MCP setup end to end.
Team and permissions covers access for people rather than machines.