Service accounts
A service account is an identity for software rather than a person. When an automation runs overnight, or an outside system needs to call BridgeApp, it shouldn’t have to log in as you. A service account gives that software its own identity — a little like a bot account with its own key. Admins create and manage them under Settings.
Why you’d use one
Section titled “Why you’d use one”Service accounts exist so that automated work has a clear, accountable identity of its own. A few common reasons:
- Run an automation as a service account. Instead of an automation acting “as you,” it can act as, say, Onboarding Bot. Now the activity it creates is clearly attributable, and it keeps working even if you’re away or change roles.
- Let an external system call BridgeApp. If you’ve built an integration that pushes data into BridgeApp, it authenticates as a service account rather than as a human.
Because the account is separate from any person, your audit trail stays clean: you can always tell which automation or integration did what.
How they sign in
Section titled “How they sign in”People sign in with a login. Service accounts authenticate with a token instead — a long, secret string the software presents to prove who it is. You generate the token when you set up the account and give it to the software that needs it.
Service accounts and agents
Section titled “Service accounts and agents”You’ll see service accounts come up alongside AI agents. When an agent works on its own — for example, posting progress on a task while no human is present — it acts through a service-account-style identity behind the scenes. That’s what keeps “who did this?” answerable even when the answer is “the agent did, on its own.”