Auxot
Tutorials Docs Pricing Login

Create a shared Team API Key

Generate an API key that belongs to a team instead of a person — so your CI pipeline, your cron jobs, and your webhook handlers don't break the day someone leaves.

Plus: three pasted Admin Agent asks — which automations deserve a `team.` key, a quarterly inventory of who created what, and rotation steps that don't break your pipeline at 3am.

Audience Admins
Time ~3 min
Prerequisites An Auxot account on **Business or Enterprise** (Team API Keys aren't available on Free or Team tiers). You're a Team Owner or Team Admin on the team that needs the key. You've finished [Generate your first API key](/tutorials/generate-your-first-api-key) — personal API keys feel familiar.
You'll end up with One Team API Key created and copied — plus a gut check for which integrations should use `team.` credentials because coworkers — not just the person who created the key — need them to keep working after someone changes roles.

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

In Generate your first API key, you generated a personal API key: one tied to your account. That works fine for one-off scripts and your own automations. But it has one quiet flaw: the day your Auxot account goes away, the key dies with it.

For most personal automation, that’s okay. For automations the team depends on (your CI pipeline, the cron job that runs a workflow every Monday, and the webhook handler that fires when a customer signs up), it’s a problem. The person who created the key leaves the company, their account is deactivated, and three different automations stop working at once. Nobody knows why until something breaks in production.

A Team API Key fixes this. It belongs to a team, not a person. The person who creates it can leave; the key stays valid. The team owns it. Anyone with the right permission on the team can rotate it. CI keeps building. Cron keeps running. Webhooks keep firing.

Today, create one Team API Key. The automation you set up won’t break the next time someone moves on.

A Team API Key is a shared credential identifying an automated service as belonging to a team. It survives staff changes, can be rotated by any team admin, and is the right key for any automation more than one person depends on.

Quick start

  1. Sign in to Auxot as a Team Owner or Team Admin.
  2. Open API Keys: Settings → API Keys.
  3. Scroll to the Team API Keys section: it’s below Personal API Keys.
  4. Click Create Team API Key: give it a clear name (something like “CI pipeline” or “Monday cron”), pick which team owns it (if you’re in more than one), and create.
  5. Copy the key: it’s shown once in a reveal panel. Copy it into the service or CI tool that’ll use it.

Done? That key now works the same as a personal API key for your automation, but it’ll keep working long after the person who created it has moved on.

The agent can do that?

Personal keys work until the person who created them leaves. Use Admin Agent Chat the same way as in Generate your first API key: prompt first, take the reply as a starting point, then update keys in Settings yourself.

1. Which automations need a Team key

Which of my current automations should be using a Team API Key instead of a personal key? Walk me through the criteria — anything more than one person depends on, anything in CI/CD, and anything that would break if I went on vacation. Be specific to my account.

Why it’s non-obvious: A cron job and a Zapier automation might share one personal key that everyone forgot belongs to a single account. The key works until that account is deactivated, then both stop at once. Send the gray-box ask; because you asked, Admin Agent shows what Auxot can see about your integrations and which ones would break if you took a week off. Auditing active keys still happens in Settings afterward.

2. Inventory keys before someone audits you

Same chat, follow-up:

List every Team API Key currently active on my account, what team it belongs to, who created it, and how recently it was used. Flag anything that looks unused, anything with an unhelpfully vague name, or anything where the creator no longer works here.

Why it’s non-obvious: Old keys accumulate. They expand your attack surface without doing anything useful. Paste this inventory ask once a quarter, read the reply beside Settings → API Keys, and revoke what looks abandoned. The conversation isn’t compliance sign-off: revoking is still your click.

3. Walk me through rotating a key without breaking anything

When you need to rotate (key was leaked, person who installed it left and you want to be sure, or you’re hitting a rotation policy):

I need to rotate the Team API Key called "[name]." Walk me through the safe sequence: create the new key, find every place the old key is configured, swap each one over, verify nothing broke, then revoke the old key. Tell me what to check at each step.

Why it’s non-obvious: Rotate carelessly and services break, which usually wakes the on-call at the worst possible time. The safe sequence hasn’t changed: create the new key → swap each consumer → test → revoke the old key. Paste that reminder when you’re nervous; you still run each swap and revocation in Settings and in whatever service holds the key. Nothing rotates itself because you chatted about it.

Go deeper

Personal vs. Team keys: the simple decision tree

Use a personal API key when:

  • Only you depend on the automation.
  • The automation is short-lived (a one-time data import, a personal experiment).
  • You’re prototyping and will replace the key later anyway.

Use a Team API Key when:

  • More than one person on the team depends on the automation working.
  • The automation runs on a schedule and you don’t want it to silently break.
  • The automation is in production CI/CD or a webhook the business depends on.
  • You want the ability for any team admin to rotate the key without locking out an individual.

When in doubt, prefer Team. The cost of upgrading personal-to-team later is one rotation cycle. The cost of a personal key dying unexpectedly is “everything stopped working at 2am and nobody knew which key was the problem.”

Why Auxot doesn’t auto-rotate or auto-expire keys

Some platforms force keys to expire after 90 days or auto-rotate on a schedule. Auxot doesn’t, and the reason is the same reason production teams hate forced rotation: it breaks things on a schedule.

Auxot’s stance: rotation is an active choice, not a calendar event. You rotate when you need to (leak, role change, audit requirement), not because it’s the third Friday of the quarter. You can build your own rotation policy on top (set a calendar reminder, run Power Move 2 above quarterly, and rotate keys with vague names or no recent use), but Auxot doesn’t impose one.

If your compliance regime requires forced rotation, set up your own scheduled job that calls Auxot’s API to delete and re-create keys, and update the consumer services in the same job. The pieces are all available.

Troubleshooting

  • The Create Team API Key button is grayed out or missing. Your role doesn’t allow it. You need Team Owner, Team Admin, or org-wide admin. Ask whoever owns the team.
  • You’re on Team tier and the section says “not included.” Team API Keys are Business/Enterprise only. Upgrade in Settings → License, or use a personal key for now (Generate your first API key).
  • You created the key but pasted it into a service and got 401 Unauthorized. Most common: extra whitespace at the start or end of the key when you copied it. Re-copy from Auxot (delete the key and create a new one, since you can’t see the old one again), paste carefully.
  • The service is using the key but Auxot doesn’t show recent activity. Either the service isn’t actually calling Auxot (check its logs), or it’s calling but failing before it makes it past auth (check the service’s error responses). Auxot’s audit logs (View your audit logs) will show every call attempt: open the Threads tab and filter by source.
  • You revoked a key and now a different service is broken. The other service was using the same key. Create a new Team key, paste it into the broken service, and restart it. (This is why Power Move 3’s “find every place the key is configured” step matters before revoking.)
  • A team member who left still shows as the key creator. That’s expected: the creator field is historical. The key itself is owned by the team and is still valid.

Variations & edge cases

  • One key per use case. Don’t use the same key for CI, cron, and webhooks. If one leaks or needs rotation, you only want to update one service, not three. Names like “GitHub Actions — production” and “Monday cron — sales summary” keep usage scoped.
  • Different teams, different keys. A key created for the Engineering team only authorizes work on Engineering-team resources. To grant Sales-team access, create a separate key on the Sales team.
  • Storing keys safely. Treat Team API Keys like passwords. Don’t paste them into a chat thread, a public repo, or an email. Use your CI provider’s secrets store, a password manager, or an environment variable on a locked-down server.
  • Rotation cadence. No platform-enforced rotation. Recommended: rotate when someone with admin access leaves, when a key is even slightly suspected of leaking, and on a calendar of your choosing for compliance. Quarterly is a common default.
  • Differentiating from Tool Connector Keys. A Team API Key authenticates services outside Auxot that call inward. A Tool Connector Key (Define a tool policy) gates things Auxot calls outward through tool workers: opposite traffic direction.
  • Multiple keys on the same team. Allowed and recommended: one key per use case (see first bullet). The team’s keys list will show all of them with their names.

Walkthrough

Step 1: Sign in to Auxot

Open Auxot in your browser and sign in. You need to be either:

  • A Team Owner or Team Admin on the team you’re creating the key for, or
  • An org admin (which can manage Team API Keys on any team).

If you’re a regular team member, the Create Team API Key button is hidden: you’ll see existing keys but can’t add new ones. Ask whoever owns the team to create the key, or to promote you.

Step 2: Open API Keys

Click Settings in the left menu, then API Keys. You’re looking at the same page Generate your first API key used to create your personal key. The page has two sections stacked vertically:

  • Personal API Keys at the top: your personal keys, scoped to your account.
  • Team API Keys below: shared keys, scoped to a team.

The page intro explains the distinction in plain English: “Use these keys when another app needs to talk to Auxot for you, without signing in through the website.”

Step 3: Scroll to the Team API Keys section

The Team section’s helper text reads: “Business / Enterprise plans: team API keys identify an automated connection for one team, useful when a service calls workflows or agents without a person signing in.”

A second helper line confirms the format difference: “Team keys start with team.“ (Personal keys start with user.: easy way to spot which is which once they’re in the wild.)

If you’re on Free or Team tier, the section is gated with: “Team API keys are not included. Upgrade to Business or Enterprise to create team-scoped service keys.” This tutorial assumes you’re on Business or Enterprise; if you’re not, head to Settings → License to upgrade and come back.

Step 4: Click Create Team API Key

The button is at the top of the Team section. Clicking it opens a modal titled “Create team API key” with the description “Give your key a memorable name so you can identify it later.”

a. If you’re in multiple teams: pick the team

A team selector dropdown appears at the top of the modal. Pick the team that should own this key. Once created, this key authorizes work on behalf of that team: its agents, its workflows, and its credentials.

If you’re only in one team, this dropdown doesn’t appear and the modal goes straight to the name field.

b. Name the key

The name field is what you’ll see in the keys list later. Helpful names match the use case:

  • “GitHub Actions — production”
  • “Monday morning sales-summary cron”
  • “Stripe webhook handler”
  • “Docs site search integration”

Bad names: “key1,” “test,” or “my key.” You’ll have several over time; descriptive names matter.

Click Create.

Step 5: Copy the key (you’ll only see it once)

A reveal panel appears with the full key value. It starts with team. and has two long base64-url segments after that, separated by dots.

Copy it now. Click the inline copy button next to the key. There’s no way to see the full key value again after you close this panel: Auxot only stores a hash, not the original value, on purpose.

If you forget to copy, no harm done: you can delete this key and create a new one. But the cleaner habit is “create the key right when you’re about to install it somewhere”: copy from the reveal panel, paste it into the service that needs it, close the panel.

Step 6: Use it where you would have used a personal key

A Team API Key works exactly like a personal API key in every external service that talks to Auxot. Drop it into:

  • CI/CD pipelines: GitHub Actions, GitLab CI, Jenkins, etc. The CI service uses the key to call Auxot’s API on every build.
  • Scheduled tasks: cron jobs, AWS Lambda schedules, Google Cloud Tasks, anything that runs on a clock.
  • Webhook handlers: services that get pinged by an external system (Stripe, Slack, or Salesforce) and need to respond by triggering an Auxot agent or workflow.
  • Service-to-service integrations: internal tools your team built that need to call Auxot programmatically.

Wherever you’d have pasted a personal key (Generate your first API key), paste this one instead.

Tip: Update old automations one at a time, not all at once. For each one currently using a personal API key (especially yours), find where the key is stored, replace it with the new Team key, run the automation once to confirm it still works, then move on. Once everything’s switched over, revoke the personal key: that confirms nothing was missed.

What’s next

Reference

Browse all tutorials