employees:read scope:
1. Resolve the employee
Your intranet knows people by email or HR id; TeamBuilder identifies them byemployee_id. Look them up once and store the mapping:
Response
email matches exactly and case-insensitively; external_id matches exactly. Filters combine with each other and with department_id. An empty data array means the person is not an active employee of your company. employee_id is stable for as long as they belong to your company, so it is safe to store.
2. Read their stats
Response
Ranks here are always all-time. For a monthly position, read the leaderboard with a
period.
3. Read their badges
Response
code is a stable identifier you can map to your own artwork. category is one of milestone, skill or social; rarity is one of common, uncommon, rare, epic or legendary. icon_url and description can be null.
Example: a profile card payload
Compose the three reads on your server into the shape your front end renders. Fetch stats and badges in parallel, and cache the card for a few minutes: XP and coins change only when people play or redeem.Node.js
Card payload
Employees who have not signed in yet
The API lists every active employee, including people who were invited or synced but have not yet signed in to TeamBuilder. For them:nameis the name your roster sync sent, ornull. TeamBuilder never reveals the name on an existing account until that person signs in to your company.- Stats are real but usually empty: level 1, no XP, no coins, no badges.
Deactivated employees
Deactivated employees vanish from every endpoint: list filters skip them andGET /v1/employees/{id}, /stats and /badges return 404 not_found. Treat a 404 as “hide the widget”. If the person is reactivated later, the same employee_id returns with their history intact.
Coins and privacy
coins reveals how much someone has earned and spent. Show it only to the employee themself, or to people your policy allows, and keep it off public leaderboards and team pages. That is why TeamBuilder’s own leaderboards omit it.