Tutorial 11

Create a shared Team API Key

Why this matters

In Tutorial 02, 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, 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. Tomorrow, the automation you set up doesn’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?

You don’t have to manage the personal-vs-team key decision alone. The Admin Agent can recommend, audit, and walk you through rotation. Three prompts.

1. Have the Admin Agent recommend which automations need a Team key

Open chat with the Admin Agent and ask:

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, anything that would break if I went on vacation. Be specific to my account.

Why it’s non-obvious: Most teams accumulate personal keys quietly — Alex set up the cron job in 2024, Jordan set up the webhook handler last quarter, both with their personal keys. Nobody thinks about it until somebody leaves. The Admin Agent can read your account’s settings (workflows, agents, integration touchpoints) and call out the ones at risk. Five-minute audit; one-incident-prevented year.

2. Audit which keys you have and which need rotation

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: Keys hang around forever once created. Old keys are security debt — the more keys exist, the bigger the surface area if one leaks. The Admin Agent has visibility into the keys and the people who created them, and can produce the audit you’d otherwise schedule a quarterly meeting to do. Run this prompt once a quarter; revoke whatever it flags.

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: Naive rotation breaks production: revoke the old key, then realize three services were still using it. The safe sequence is create new → swap services one at a time → verify → revoke old. The Admin Agent can talk you through each step in order, with the right verification at each one. Rotations stop being scary once someone’s walking you through them.

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, 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 (Tutorial 02).
• 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 (deletion + new key, 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 (Tutorial 12) 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, 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 external services calling Auxot. A Tool Connector Key (Tutorial 08) authenticates tool workers being called by Auxot. They’re opposite directions. Same word “key,” different jobs.
• 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 Tutorial 02 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, 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,” “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, 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 (Tutorial 02), 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

• → Tutorial 02: Generate your first API key — re-read if you want a refresher on the personal-key flow before deciding what to migrate.
• → Tutorial 06: Invite your first teammate — Team API Keys exist because team membership changes. Tutorial 06 covers the other side of that coin.
• → Tutorial 08: Define a tool policy — different concept (Tool Connector Keys), but worth distinguishing if both come up in the same conversation.

Reference

• Pages in Auxot: Settings → API Keys (Team API Keys section)
• Tier required: Business or Enterprise
• Permissions: Team Owner, Team Admin, or org admin can create
• Key prefix: team. (vs user. for personal keys)
• Lifetime: No automatic expiry — survives until manually revoked
• Storage: only a hash; the plaintext is shown once at creation
• Rotation: delete + create new (no in-place key change)
• See also: Tutorial 02: Generate your first API key, Tutorial 06: Invite your first teammate, Tutorial 08: Define a tool policy