Credentials - MixShift admin

Sign in

Use your MixShift account login. Anyone who can sign in to this tenant can manage its credentials.

No MixShift account yet? Create one, then activate your data (getting started guide) and return here to manage credentials.

How service credentials work what they are, why, and what to do with one

What: a service credential is a machine key (a client_id + secret pair) for things that run without a person present: scheduled Cowork tasks, cloud automations, CI jobs. Humans signing in interactively don't need one; their browser sign-in handles it.

Why: browser sign-ins need someone to click a link, and their tokens rotate. A schedule that wakes up at 9am with nobody at the keyboard can't do either. The service credential is static, so it survives restarts, fresh sandboxes, and read-only secret stores, and it mints short-lived (1 hour) access tokens on demand. Tokens are read-only unless you grant Amazon Ads write access when creating the credential.

How to set one up:

Click Create service credential below and name it after the automation (e.g. nightly-foep-watch). You'll get the client_id and a secret, shown exactly once.
On the machine or workspace where the automation runs, save the secret into a file (use an editor or secret manager, not a shell command that would land in history).
Run the mixshift auth service-setup command we'll show you after creation. It verifies by minting a real token, then your automation authenticates itself from then on.

Afterwards: activity shows up attributed to the credential's svc: label. You can revoke instantly or rotate with zero downtime from this page, any time. Full guide: service credentials documentation.

Service credentials

Machine keys for scheduled tasks, automations, and CI. Static secrets used with the OAuth client_credentials grant; revoking kills new token mints immediately.

Label	Client ID	Scopes	Created	Last used	Status

Also grant Amazon Ads write access (ads:write) - lets this automation apply audited Ads changes: bids, budgets, states, negatives, campaign creation. Writes still default to a dry-run preview and every committed change is audit-logged. Leave unchecked for read-only (the default and the right choice for most automations). Applies to both create options: the setup code and the raw secret. Also grant Amazon Listings write access (listings:write) - lets this automation apply audited listing-content changes: title, bullets, description, keywords, ingredients, item form, and product images including replacing the main product image. Every change previews first (nothing reaches Amazon until the exact change set is approved) and each committed change is audit-logged. Note image changes apply asynchronously: Amazon accepts the submission, then fetches your image and re-hosts it, so acceptance is not publication and a failed fetch shows up later in the listing's issues. Leave unchecked for read-only. Also grant Brand Context write access (context:write) - lets this automation publish and update brand context docs in the org store. Every write is attributed and versioned (optimistic concurrency + append-only history), so nothing is silently overwritten. Leave unchecked for read-only. Also grant Brand Timeline write access (timeline:write) - lets this automation append events (structural notes, comments) to the org timeline. Appends only; existing history is never modified. Leave unchecked for read-only. Also grant MixShift Intelligence read access (intelligence:read) - lets this automation run the Intelligence analyses: the insight catalog, analysis runs, and their results. Read-only: running an analysis changes nothing in your account. Intelligence is on for every account by default, so this grant is all the automation needs. Applies to both create options.

The setup code (valid 10 minutes) is for a workspace running the MixShift plugin: paste it to Claude there and the credential is issued straight into that machine, with no secret to handle. Running your own code, a server, or CI instead (no plugin)? Create a raw client_id + secret and exchange it yourself with the client_credentials grant (see the developer docs):

Setup code created. Paste it to Claude within 10 minutes.

This flow is for a workspace that already runs the MixShift plugin. If instead you are wiring up your own code or a server (no plugin), you do not need this: close this box and choose "Create with raw secret" below, then exchange it yourself per the developer docs.

What to do

Go to the Claude (Cowork / Claude Code) workspace where the automation will run.
Say: "set up a service credential" and paste the code when asked - or just paste the code with that ask. Claude runs and the credential is issued straight into that machine. The code is single-use and expires in 10 minutes; nobody ever sees the secret.
The credential appears in the list above once Claude exchanges the code.

Detailed guide: service credentials documentation

Credential created. Copy the secret now - it is shown exactly once.

Next steps (3 minutes)

On the machine or workspace where the automation runs, save the secret into a file named mixshift-secret.txt. Use an editor or your secret manager; avoid shell commands that would put the secret in history.
In that workspace, run this command (it verifies by minting a real token):
Delete mixshift-secret.txt. Done - the automation now authenticates itself. Access is limited to the scopes shown in the list above (read-only unless you granted Ads write), and you can revoke or rotate here any time.

Detailed guide: service credentials documentation

Active sessions

People signed in interactively - plugin sign-ins and partner app grants. Machine keys live on the Service credentials tab. Revoking ends that session's ability to refresh, but it does not kill the access token already issued: that keeps working until it expires, up to 12 hours for a partner app grant and up to 24 hours for a plugin sign-in. If you need an immediate cutoff, contact MixShift.

Person	Device / app	Client	Created	Expires