Skip to content

Project vs. private credentials

Every credential type a toolkit can use offers the same choice: a project credential or a private credential. The toolkit’s credential field states it plainly — project credentials are shared with the project team, private credentials are visible only to you.

  • Project credentials make sense when a toolkit is shared team infrastructure — a project’s GitHub or Jira connection that everyone on the team should be able to use without holding their own token.
  • Private credentials make sense when each teammate should authenticate with their own identity — for example, so that actions a toolkit takes (a Jira comment, a GitHub commit) are attributed to the person who triggered them, not to a shared service account.

A toolkit instance references one credential at a time. If you want per-user attribution on a team-shared toolkit, each teammate creates their own private credential of the matching type, then selects it in their own copy of the toolkit’s configuration (or in whichever context lets them pick a credential, such as an inline chat editor).

In your personal project vs. a team project

Section titled “In your personal project vs. a team project”

In your personal project, “project credential” and “private credential” describe the same access — only you can see either one — so the distinction mostly matters once you’re working in a team project with other members. There, the choice determines whether a teammate opening the same toolkit sees your credential in the dropdown at all.

A reasonable default: start with a project credential for anything genuinely shared (a bot account, a service integration), and reach for a private credential the moment attribution or personal access scope actually matters — for example when a toolkit posts comments, opens pull requests, or otherwise takes an action that should trace back to an individual rather than the team.