Skip to content
Y
YAS.SH
Teams

Teams & Permissions: Running Link Infrastructure With Guardrails

Role separation, API key scoping, and review workflows for teams sharing one link platform — without stepping on each other.

yas-team3 min readteamspermissionsapi keys
Teams & Permissions: Running Link Infrastructure With Guardrails
Featured imageTeams & Permissions: Running Link Infrastructure With Guardrails

Once a team shares a link platform, the question stops being "can everyone reach it?" and becomes "can everyone do everything?" Shared infrastructure without guardrails produces collisions, mystery deletions, and keys that outlive their owners. This guide is the permission model that works: roles for humans, scopes for machines, review for destruction.

Humans: roles with a ceiling

The role ladder that fits most teams:

Role Can do Ceiling
Member Create links, view own analytics Cannot touch others' links
Manager Everything in the workspace
Auditor Read everything Cannot create or delete

The operational rule: the person who creates a link owns it; managers intervene only on escalation. This keeps accountability simple — every link has exactly one owner, and the audit trail ("which key, which link, when") stays unambiguous.

Machines: scoped API keys

Automation should never hold a human's power. The API key model is the enforcement layer:

links:read        → dashboards, audits, exports
links:write       → creation pipelines, campaign builders
analytics:read    → reporting jobs, alerting

Concretely: the marketing intern's campaign script gets links:write + analytics:read — it can create links and read their performance, but it cannot delete, and it cannot touch keys. The CI pipeline gets links:write only. Nothing gets all three except the team's lead key, rotated quarterly.

The review workflow for destructive actions

Deletion is the one action that needs ceremony:

  1. Delete via API or dashboard — the link and its events are removed.
  2. Confirm the blast radius — is the link in print? In an active email? Expiring links with 410 (expiry guide) are the graceful alternative to deletion.
  3. Archive first when uncertain — export the CSV before any bulk cleanup (bulk guide); CSV is the safety net.

The rule: expire what might be needed, delete what's provably dead, export before both.

The audit habit

A 15-minute monthly review keeps permissions honest:

  • Keys: names, scopes, lastUsedAt. Keys unused in 90 days get revoked; keys with suspicious scope get narrowed.
  • Links: the organization workflow review — dead links expired, titles fixed.
  • Members: offboarded humans' sessions die at their 30-day expiry; revoke any keys they created.

The API returns everything the audit needs: key lists with last-used timestamps, link exports, analytics per link.

Common failure modes

Failure Guardrail
Shared personal logins Sessions are personal; keys are the sharing unit
One all-powerful key in CI Scope by pipeline; rotate quarterly
Intern keys surviving the internship Revoke on offboarding, always
Mystery deletions Owner-only delete + expiry-first culture
Audit-blind teams Monthly key/link review from API exports

Conclusion

Team infrastructure needs roles for humans, scopes for machines, and review for destruction. The API key scopes implement the machine half; the owner model implements the human half; the monthly audit habit keeps both honest. Set up the workspace the way the key best practices describe, and the platform scales with the team instead of against it.

Frequently asked questions

How do teams share one link workspace safely?

The pattern is: humans get scoped roles, machines get scoped API keys, and destructive actions go through review. On yas.sh, API keys carry scopes (links:read, links:write, analytics:read) so automation is least-privilege by construction.

What's the difference between a session and an API key?

Sessions identify interactive users through the dashboard and expire quickly; API keys identify automations and live longer. Never share a personal session; keys are the sharing unit for machines.

What permissions should an intern's automation have?

The least that does the job: links:read to audit, links:write to create in their campaign, analytics:read for reporting. No key revocation gaps — keys are revocable instantly.

How do I audit what my team did?

Key names, scopes, last-used timestamps, and link/analytics history give the audit trail: which key created which links and when they last authenticated.

Was this helpful? Share
🍪 Cookies & privacy. yas.sh uses only essential cookies to keep you signed in and remember your preferences. We do not run third-party trackers. See our cookie policy and privacy policy.
Settings