Profiles and imports
Read a profile
Section titled “Read a profile”Your backend calls getProfile(userId) with profiles:read. Browser and mobile clients access only their own profile through the user-bound route.
A profile includes total score, level, configured streak state, named balances, achievement counts, and daily scoring state. Use the API schema for required and nullable fields.
The contract also exposes prestige_count. The current API initializes it to zero; a public prestige-reset operation is not implemented. Do not build a reset workflow around this field.
Import existing progress
Section titled “Import existing progress”Before sending new events for an existing user, import their current progress with a server token carrying profiles:write:
await streakline.importProfile(userId, { idempotency_key: `migration:v1:${userId}`, total_score: 1250, streaks: { "daily-practice": { current_streak: 4, longest_streak: 12, last_qualified_period: "2026-09-08", }, },});daily-practice must match a configured streak key in the active environment. The API derives the internal configuration signature. Repeating the same import key returns the current profile without overwriting live progress.
Streak period keys
Section titled “Streak period keys”| Period | Format | Example |
|---|---|---|
| Daily | YYYY-MM-DD |
2026-09-08 |
| Weekly | Monday’s date, YYYY-MM-DD |
2026-09-07 |
| Monthly | YYYY-MM |
2026-09 |
Partial progress within an unfinished period is not imported. Subsequent events build that progress under the active rules.
Verify the migration
Section titled “Verify the migration”Read the profile after import and inspect getEvents(userId, 100) as you start sending events. Compare total score, local dates, and configured streak state with your expected migration values. Use a QA environment before migrating production users.
Delete a user
Section titled “Delete a user”With profiles:delete, call await streakline.deleteUser(userId) from your backend’s account or profile erasure workflow. Success has no response body.
After server-side erasure succeeds, clear local SDK state with clearUserData(). Do not continue sending queued events for the erased identity.