Skip to main content

Player Progress API

This page assumes the shared rules in API Conventions — authentication, the two error shapes, batching and identity resolution. It only covers what is specific to progress.
The Player Progress API lets your backend read where each collaborator stands in your company’s gamification: which level they are on, how much XP they have, how many coins they can spend, and their position in the ranking. It was built for the band at the top of a home screen — the one that greets the person and shows how they are doing.
The level ladder is configured by your company: how many levels, their names, what each one requires, and how each one looks. This API returns whatever is configured — it knows no specific ladder.

How It Works

  1. You get an API Key with the progress:read scope
  2. Your backend asks for one or many collaborators (by CPF or email)
  3. SalesOS answers with the ladder once at the top, then each person’s state

Authentication


Endpoint Reference

One action: progress_status.

Request Schema

string
required
Must be "progress_status"
array
required
Array of collaborator references (max 500)
string
Period for XP and ranking: daily, weekly, monthly or all_time. Absent = all_time.
string
Ranking universe: tenant (everyone in the company) or org_unit (the person’s own unit). Absent = tenant.

Example

Response (200):

Fields

The ladder (top level)

The number of levels is your company’s, not a constant. Build the screen from the array. A ladder can have nine rungs where another has ten, and both are correct.

Per collaborator


Level appearance

The level’s visual identity — its color, and anything else your company configures — comes back in appearance.
appearance can be null, and null does not mean “no color”. It means nobody has configured one yet. Render your own fallback in that case, but do not hardcode a palette keyed by level name: the day your company renames a level or changes its colors, a hardcoded screen keeps showing the old one, with no error anywhere.
Read the color from the response even when it looks constant today. That is the whole reason it travels in the payload instead of living in your app.

Periods

XP is stored in four periods, and the screen usually shows one of them. Because “200 XP” on a design does not say which, this API returns all four plus the one you asked for.
An unknown period is rejected with 400, not answered with zeros. A response full of zeros would make your screen state that the person has no XP — an absence that is not true.
A period that was never measured comes back absent, not as 0. In the example above weekly is missing: that person has no weekly score row. daily: 0 is different — it was measured, and the result was zero.Treat the two apart. Writing “0 XP this week” for an absent period tells the person they scored nothing, when the truth is nobody computed that period for them.

Ranking

A position only means something alongside its universe, so scope, period and total always travel with it.
total is how many people the position was measured against. “#12 of 240” reads very differently from “#12 of 13” — show it.

Error Handling

See API Conventions for the two shapes and the status code table.
Invalid body, batch over 500, CPF without 11 digits, an item with neither cpf nor email, or an unknown period / ranking_scope.
API key is valid but lacks the progress:read scope.
A company with no ladder configured is not an error. The response comes back with levels: [] and status 200.

Rate Limits


Next Steps

Missions API

The progress that earns the XP shown here

Campaigns API

Where the coins get spent