Skip to main content

Introduction

SavageTech missions are small, trackable challenges (for example: “place 10 bets”, “make a deposit”, “defeat 3 opponents”) that you can show inside the widget to keep players engaged.

At a high level:

  • A mission defines what to do and how much to do (target count + qualifiers).
  • Each player has multiple mission slots (think “challenge cards”).
  • Player activity (bets, deposits, combat events, etc.) progresses those slots automatically.
  • When a slot hits its target, it becomes ready to claim, and claiming it grants rewards.

The lifecycle of a mission slot (plain English)​

What “qualifying activity” means​

Missions can be tied to real events in your product (for example deposits and bets) and/or in-widget gameplay events (for example opponents attacked/defeated).

From an integrator perspective, the important bit is:

  • Your system sends activity (like bets/deposits) into SavageTech.
  • SavageTech matches that activity to mission rules and advances progress.

Managing missions (vendor/admin)​

Mission definitions are managed through the vendor-side missions endpoints (see OpenAPI for full schemas):

  • GET /api/v1/missions — list missions
  • POST /api/v1/missions — create a mission
  • GET /api/v1/missions/:id — read one mission
  • POST /api/v1/missions/assign — assign missions to players
  • POST /api/v1/missions/bulk-upload — bulk upload missions

Common questions​

“Do I have to calculate mission progress myself?”​

No. You send the underlying activity; SavageTech handles counting, thresholds, and “ready to claim” status.

“What happens when a mission is completed?”​

When the player claims a completed mission slot, SavageTech converts the mission rewards into player rewards and grants them (for example inventory items, currency, external rewards, etc.).