Drıftstack docs
Docs

Working in a team owner’s workspace (roles, what a member sees)

You might be here because: “Acting as” · “how do I see my team owner’s profiles” · “I’m on a team but only see my own account” · “switch workspace” · “my program works on my account, not the team” · “member can’t see agent sessions (403)” · “proxy shows no address in the team” · “whose limits apply on a team” · “the owner sees what I did”

Short answer

A team is one owner account plus the members who accepted an invite. In the dashboard, the Acting as picker in the sidebar switches between your own account and each owner team, remembers your choice in that browser, and applies it to everything the dashboard does. A program switches by sending the owner’s account id with each request; the owner reads that id from the key-check endpoint and shares it.

Check first

  • On the team? Invites are accepted in the dashboard, signed in with the exact invited address; the API does not manage membership.
  • Which role? member reads, admin reads and writes; the owner chose it when inviting you.
  • Is the picker on your own account? That is the default.

Likely causes and fixes

  1. “I only see my own things.” The picker is on your own account, or your program is not sending the owner’s id. Fix: choose the owner team under Acting as; in code, send the owner’s account id on every request.

  2. 403 as a member on agent sessions, recipes, live session state or the API key list. These need admin even to read: an agent session carries the AI transcript and live control, a recipe is a saved copy of those steps, live state returns the session’s cookies, and the key list names the owner’s keys and key prefixes. The plain session list still works. Fix: ask the owner for the admin role, or ask an admin.

  3. Proxies show only a label, scheme, country and status. A member gets a narrow row — never the address, username or whether a password is stored; an admin reads and writes the owner’s proxies.

  4. Whose limits apply. A session in the owner’s workspace counts against the owner’s concurrent cap and uses the owner’s profile data; the proxy cap and VPN entitlement are the owner’s plan. Session requests draw on your rate limit first, then the owner’s.

  5. Your key’s permissions still apply. The role decides whose resources you reach; your key’s scopes decide what it may do there — the owner’s webhooks need a full-access key even for an admin.

  6. The owner sees what you did. Your actions on the owner’s resources go to the owner’s audit log, naming you where the endpoint records who acted. If the owner removes you, the switch stops working at once; your own account stays.

If it still fails

Press Talk to a person in this chat (or open Help) and include: the owner’s account email, your role as the owner’s Team page shows it, the workspace selected, and the exact 403 sentence.