Authorize User API behavior: nonce, player creation, player_info upsert, and segments

This article explains how POST /s2s/v1/users/authorize behaves in server-to-server integrations, including when to use nonce, how player creation works, how player_info is applied, and why segments is not part of the request.

nonce is optional for S2S flows

For server-to-server use cases, calling Authorize User without nonce is supported and safe.

• nonce is used for the desktop QR-code authorization flow.

• For normal S2S authorization, you can omit it.

• The response contains a signed, single-use login URL that is cryptographically bound to the provided player_id.

This login URL is the secure alternative to manually constructing a deep link such as /go/login?player_id=<id>.

Player creation behavior

• Update Player returns 404 if the player does not already exist.

• Authorize User performs get-or-create by player_id.

This means Authorize User can be used both to generate a login URL and to provision a player record ahead of first login.

player_info support on Authorize User

The Authorize User endpoint supports an optional player_info object in the request body.

{
  "player_id": "han-solo-42",
  "player_info": {
    "name": "Han Solo",
    "avatar_url": "https://example.com/han.png",
    "attributes": {
      "hard_currency_amount": 500
    },
    "custom_attributes": {
      "faction": "rebel"
    }
  }
}

Supported player_info fields:

• name — player display name

• avatar_url — player avatar URL

• attributes — persistent player attributes

• custom_attributes — free-form game-specific key/value data

player_info update behavior

player_info now supports full upsert behavior on Authorize User.

• If the player does not exist, Authorize User creates the player and applies player_info.

• If the player already exists, Authorize User updates the existing player using the provided player_info.

• A separate Update Player call after Authorize User is no longer required when you are already sending the desired player fields in player_info.

Why segments is not included in player_info

This is intentional.

• player_info is limited to profile data owned by the game: name, avatar_url, attributes, and custom_attributes.

• Segments are a derived concept on the platform side.

• Segments are assigned automatically by segmentation rules based on attributes, custom attributes, and behavior, or managed through the /v1/segments S2S endpoints.

• The player’s resulting segments are returned in the verify-player webhook response.

Recommended pattern:

1. Send profile data through player_info.

2. Let segmentation rules or the segments S2S endpoints manage segment membership.

3. Read assigned segments from the verify-player webhook.