API keys and sign-in providers

Two pages in Settings hand out access to your store. Settings → API keys is for outside systems (scripts, warehouse tools, AI tools that run from a terminal). Settings → Customer login is for your shoppers, who can sign in to the storefront with Google, Facebook or GitHub. Connecting an AI assistant such as Claude or ChatGPT is not a settings page: use the MCP button in the top bar, or the MCP row in your user menu.

These pages used to be one Authentication page. If you are looking for it, API keys and Customer login are now two separate entries in the Settings menu, and an old link to /settings/oauth redirects to Customer login.

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

1. Go to Settings → API keys. The page opens for anyone with View API keys; Create API Key, Rotate, Deactivate and Revoke need Manage API keys.
2. Click Create API Key.
3. Fill in the form (table below).
4. Click Create, then copy the key immediately from the API Key Created window and tick I've saved the key to close it.

The key is shown once. There is no way to see it again, and the page only ever keeps its first characters. If you lose it, Rotate it (below) to get a fresh secret without rebuilding the key.

What the form does not have. There is no tier picker: a key's quota follows your plan automatically. There is no expiry date and no "test key" option in the dashboard, so every key you create here has no expiry. Keys with an expiry date or a brainerce_test_ prefix can only be created through the API, and a brainerce_test_ key is not a sandbox: it reaches the same store with the same permissions. See API authentication.

What each key row shows

Each key is a card with its name, an Active or Inactive badge, a TEST badge if it carries the test prefix, its plan Tier (plus its own per-minute override when set), its first three permissions followed by "+N more" (or Full Access), the number of allowed IPs, Created date, Last used date (or Never) and Expires date when it has one. The buttons on a row are Deactivate or Activate, Rotate, View activity and Revoke. A revoked key disappears from the list; there is no "Revoked" filter and no way to bring one back.

A key called "AI Integration" may be in your list from an earlier version. Brainerce used to create it for you, with Full Access, when the store owner loaded the dashboard. It no longer does: nothing creates this key any more, and nothing in Brainerce uses it (the AI assistant and the built-in tools work through your dashboard sign-in, not through an API key). If you see one, you can revoke it, and it will not come back, whether you deactivate it or revoke it. Treat it like any full-access key: never paste it anywhere. Every key you create yourself carries only the permissions you tick.

Choosing permissions

Permissions are split into five groups (Catalog, Sales, Marketing & Content, Developer, Account & Admin), and each area has a Read and a Write box. A few areas have one box only, such as Customer auth or AI assistant. Write does not include Read: a key with only Orders: Write cannot list orders, so tick both when the integration needs both.

The full list of permission names (the products:read form that appears in your code), what each one unlocks and which ones only the account owner can grant is in API authentication: API key scopes. This page does not repeat it.

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 offers shortcuts:

• Start from a preset: Custom (clears everything), Storefront (the catalog reads plus cart, checkout and customer sign-in a storefront needs), Read-only (every Read box and nothing else) and Full access (every box in the dialog). Changing a box by hand switches the highlighted preset back to Custom.
• A tick box on each group heading that selects the whole group, a Filter permissions box, Select all, All read-only and Clear, and a running count ("N selected").

Select-all and Full access are convenient while you're experimenting; they are the wrong choice for a key you're about to deploy. Full access is not an unlimited key: it ticks the boxes the dialog offers, and a few permissions (Events, Donations, SEO) have no box at all, so a dashboard key can never reach them.

Which API key scopes can a manager grant? Team members and owner only permissions

A manager (or any team member with the API keys permission) can grant only the scopes that match permissions they hold themselves. The account owner can grant every scope. A scope is a permission on an API key, such as products:read or orders:write.

These areas have no matching team permission, so only the account owner can grant them: Media, Metafields, Cart, Checkout, Shipping, customer login and sign-up (Customer auth), Reviews, Email, OAuth providers, Store (read), Regions, Tax, Tax classes, Team (read) and Sync (retired). Everything else, for example Products, Orders, Inventory, Customers, Coupons, Discount rules, Content, Blog, Analytics, Settings and Webhooks, can be granted by a member who holds the matching permission. The exact scope names are in API authentication: API key scopes.

Some permissions can only be granted by the account owner: Cart, Checkout, Media, Shipping, Reviews, Regions, Tax and a number of others. If you are a team member with the API keys permission and not the account owner, the dialog shows those rows greyed out with "Only the account owner can grant this", and you cannot tick them. You can still grant the permissions you hold yourself, such as Products or Orders.

The presets follow the same rule. For a team member, Storefront, Read-only and Full access tick only what you can grant, and a note under the presets says how many permissions were left out. Storefront needs Cart and Checkout, so a team member who is not the owner cannot build a complete storefront key. Ask the account owner to create it. The account owner sees every permission enabled and every preset in full.

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: 60 requests a minute on Free, 500 on Pro, 2,000 on Growth and 10,000 on Enterprise.
• An IP allowlist (optional), one IP address or CIDR range per line, so only these addresses may use the key. Leave it empty to allow any address. Rejected attempts are logged with the source IP. 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.

Pause a key without losing it

Deactivate on a key's row switches it off, and Activate switches it back on. A deactivated key keeps its name, permissions and secret but every request with it is refused until you activate it again. Use it for a short freeze. It is not the same as Revoke, which cannot be undone.

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.

Sign-in providers

Settings → Customer login 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. Only Google, Facebook and GitHub exist; there is no Apple, Microsoft or X sign-in. The page needs the Manage store settings permission.

What the Customer login page shows

• The Google card marked Built-in (platform-managed, nothing to configure) with an Active or Disabled switch and a Use your own credentials button. Disabling it asks you to confirm ("Customers will no longer be able to sign in with this provider. You can re-enable it at any time").
• A card marked Custom for every provider you added with your own credentials, with Active or Inactive, the date it was last Updated, an on/off switch, Edit and Remove Configuration. Removing it asks you to confirm and does not delete any customer account.
• Available to connect lists the providers you have not added yet. Add Provider (or Add Your First Provider when the page is empty) opens a form with Provider, Client ID and Client Secret (all three required), an Enable Provider switch and a copy button for the Authorized redirect URI.
• To change a custom provider, Edit shows the Client ID and an empty Client Secret. Leave the secret empty to keep the existing one.

Google sign-in works out of the box, but the consent screen says Brainerce

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.

Put your own store's name on the Google sign-in screen

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:

1. Your own Google OAuth client, with Brainerce's callback URL registered on it (next section).
2. Your branding filled in on your own domain: app name, logo, homepage, privacy policy, terms.
3. 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.

Add Brainerce's callback URL to your Google client, or sign-in fails with redirect_uri_mismatch

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.

1. On the built-in Google card, click Use your own credentials.

2. In Google Cloud Console, create an OAuth client of type Web application.

3. 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.

4. 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 page. 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.

Connect an AI assistant

MCP in the user menu connects an AI assistant (Claude, Cursor, ChatGPT) directly to your store. It opens a popup with the MCP address and a small icon for each assistant (Claude, ChatGPT, Cursor, Claude Code); point at an icon to see its setup steps. The row appears only for people who can view API keys. See Connect an AI assistant for the full walkthrough.

Audit log

The audit log records what happens to your API keys: a key being created, updated, rotated, revoked or deleted, and requests that were refused because the caller's IP is not on the allowlist, the key lacks the permission, the key has expired or the key is deactivated. When something looks wrong you can see which key it was and when. Open it with the Audit log button at the top of Settings → API keys. Each key's row also has View activity for just that key.

The log lists the newest events first, 50 per page, with Previous and Next and a Refresh button. A row of filter chips narrows it: All, Authentication rejected: IP not in allowlist, Authentication rejected: key expired, Authentication rejected: key inactive, API key created, API key rotated, API key updated, API key deactivated and API key deleted. Rejected attempts carry a Security badge and show the source IP. The log also records the first successful sign-in from a new IP address ("Authentication succeeded from new IP"), and when the source IP of a key changes. Deactivate is logged as "API key deactivated"; Revoke is logged as "API key deleted".

The log is not a record of every request a key makes: ordinary successful calls are not listed, and the chips have no filter for a rejection because of a missing permission, although those events appear under All.

What's next?

• 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.