Understand Credentials, OAuth, and API keys in Auxot

Open **Settings → API Keys**, **Settings → Credentials**, and **Settings → OAuth** once each, learn which direction each secret travels (into Auxot versus out to vendors), and stop pasting the wrong kind of key into the wrong box.

Plus: three Admin Agent prompts that build a one-page cheat sheet for your team, route a real integration to the right bucket, and sanity-check scope before you save anything.

Audience	Everyone · Admins · Developers
Time	~5 min
Prerequisites	You can open Settings and you already know the shell layout ([Find the right screen for your next question](/tutorials/find-the-right-screen-for-your-next-question)). Helpful: you created or skimmed a personal key once ([Generate your first API key](/tutorials/generate-your-first-api-key)).
You'll end up with	A three-row mental model (API keys, credentials, OAuth), one slow pass across the three Settings pages, and three Admin Agent prompts you can paste into Chat when a coworker asks which secret goes where.

When a tutorial shows italic text in quotation marks, it usually mirrors a label or helper string inside Auxot. Product copy changes between releases — if something reads differently in your workspace, trust what you see on screen.

Callouts with a Worth knowing gold accent are meant as must-read context before you move on. Blockquotes that open with Tip are lighter, optional depth.

Why this matters

Secrets are not interchangeable. API keys authenticate callers into Auxot (scripts, CI, other services using your HTTP APIs). Credentials store secrets Auxot uses when it calls out to GitHub, Stripe, your CRM, or an internal HTTP endpoint while an agent or tool runs. OAuth is the step where a human delegates vendor access to Auxot so per-user tool calls can use their token instead of a shared password in a text field.

When those three blur, people paste a GitHub PAT into API Keys, or they put an Auxot user. key into a vendor’s webhook config, or they wonder why MCP keeps saying connect your account when nobody opened the OAuth half.

Today, you open each page once and write a three-line cheat sheet in your own notes. The next time someone Slacks which key, you send the cheat sheet instead of guessing.

This is vocabulary work, not a security audit. Your org still owns rotation policy, least privilege, and who may see admin-only pages.

Quick start

Open Settings → API Keys: read the page framing. These keys identify who is calling Auxot’s APIs from outside (Generate your first API key).
Open Settings → Credentials: read how stored secrets are named, scoped, and injected. These values let Auxot call outward on behalf of agents or integrations (Manage your Credentials).
Open Settings → OAuth: scan provider rows if your role can see them. This is where org-wide OAuth apps and per-user delegation for tool calls are wired (Connect OAuth for MCP tools).
Write three lines in your notes: one sentence each for into Auxot, out from Auxot, and human delegation (OAuth). Use your own vendor names if that helps memory.
Paste prompt 1 from below into Chat → Admin Agent and save the reply next to your three lines.

Done? You can point at the correct Settings page for script hits our API versus agent posts to GitHub without opening every tab.

The agent can do that?

You already saw the three surfaces once. These prompts ask the Admin Agent to teach the team in plain language without storing new secrets in chat. Paste into Chat → Admin Agent.

1. Build a shareable cheat sheet

Build a markdown table with three rows: Auxot API Keys, Auxot Credentials, Auxot OAuth (MCP-oriented). Columns: what it is for, example mistake, and the Settings path to open. Keep each cell under twenty words. Use Auxot UI labels literally.

Why it’s non-obvious: The words key and token repeat everywhere. A forced table separates API key, credential, and OAuth row so new hires stop repeating whatever string they saw last without knowing which page it belongs on.

2. Route one real integration to the right bucket

Integration: [name a real system like GitHub, Stripe, Slack, internal REST]. Direction of trust: [humans click Auxot versus scripts call Auxot versus agents act in the vendor]. Tell me whether to use API Keys, Credentials, OAuth, or a combination, and name the first Settings page I should open. If you need an admin, say so plainly.

Why it’s non-obvious: Many systems participate in two directions at once (webhook in, API out). Splitting the first hop prevents the wrong object from being created under pressure.

3. Sanity-check scope before you click Save

I am about to create [API key / credential / OAuth row] at scope [org / team / user]. List three ways that scope could surprise a teammate next week. If narrower scope is safer, say what to pick instead and why in one sentence each.

Why it’s non-obvious: Scope mistakes look fine on day zero and hurt on day ten when rotations, audits, or a departing laptop surface who could always read what.

Go deeper

Linked Accounts are not the same as MCP OAuth

Settings → Linked Accounts is where you link Slack or Discord identity so chat apps know which human you are (Link your chat apps to your Auxot account). That is a different problem from OAuth rows that back MCP tool calls (Connect OAuth for MCP tools). Same word OAuth on the internet, different Settings page in Auxot.

Prefixes on API keys (`user.` versus `team.`)

Personal keys start with user. and follow the human who created them. Team keys start with team. and are meant for shared automation. If your question is which prefix for CI, read Pick personal or team API keys for real work next.

Tool policies and tool connector keys

When agents gain powers beyond plain chat, tool policies and connector keys enter the story (Define a tool policy). Treat that as day-three depth after the three-row model stops feeling fuzzy.

Walkthrough

Step 1: API Keys first on purpose

Open Settings → API Keys. Read the helper copy slowly. If you create nothing today, that is fine. You are anchoring this page is for callers into Auxot.

Step 2: Credentials as outbound secrets

Open Settings → Credentials. Notice naming and scope fields. You are anchoring this page is for secrets Auxot carries when it acts elsewhere.

Step 3: OAuth as delegated trust

Open Settings → OAuth. If the page is empty or admin-only for you, note that fact on your cheat sheet instead of forcing a demo you cannot complete.

Step 4: Reconcile vocabulary with Linked Accounts

Open Settings → Linked Accounts once. Confirm it answers who am I in chat apps rather than how does MCP call GitHub as me.

Step 5: File the cheat sheet where invites land

Drop your three-line note (plus the Admin Agent table if you generated it) into the same place you drop onboarding links (Verify your org is ready before you invite, Invite your first teammate).

What’s next

→ Generate your first API key. When you are ready to create a real API Keys row for a script or SDK.
→ Manage your Credentials. When an agent truly needs outbound access to a vendor API.
→ Connect OAuth for MCP tools. When MCP tool calls should use per-user vendor tokens.
→ Pick personal or team API keys for real work. When automation needs the right prefix and audience.
→ Define a tool policy. When capabilities, not just secrets, need guardrails.
→ Run an agent on a schedule. One prompt on a clock, natural once outbound secrets and tool paths are no longer a blur.

Reference

Pages in Auxot: Settings → API Keys, Settings → Credentials, Settings → OAuth, Settings → Linked Accounts
Direction mnemonics: into Auxot (API keys), out from Auxot (credentials), human delegation (OAuth for MCP paths)
See also: Add an MCP server, Harden your intake webhooks, Create a shared Team API Key, Know when Workflows beat a long Chat thread, Run an agent on a schedule