Streak Logs
Streak Logs are the activity events that drive streak progress. Every time an end user performs a qualifying action — a purchase, a visit, a workout — your backend sends a Streak Log entry. The platform aggregates these entries according to the streak's aggregationMethod and aggregationPeriod, updating the user's Streak Progress for the current period automatically.
Streak Logs can only be created via the API (CREATE, GET, LIST). They cannot be updated or deleted. Once submitted, a log entry is permanent.
How it works
- User performs an action — a customer places an order, visits a store, or completes any activity your streak tracks.
- Your backend sends a log — call
POST /schema/streak_log/recordwith thestreakId,ownedById,activityAt,uniqueIdentifierandactivityValue(Required whenaggregationMethodof theStreakschema issum). - Progress updated — the platform aggregates the new entry into the user's
Streak Progressfor the current period, updatingcurrentProgressValue. - Milestone triggered — if
currentProgressValuecrosses a milestone'smilestoneTargetValue, aReward Logis created andachievedMilestone+achievedMilestoneRewardLogare set on the response. - Period completed — if
currentProgressValuereaches the streak'saggregationTargetValue,streakProgressStatustransitions tocompletedfor that period and the streak's consecutive count increments.
Fields
Required on create
| Field | Type | Required | Description |
|---|---|---|---|
streakId | UUID | ✅ | ID of the streak this log contributes to |
ownedById | UUID | ✅ (or use ownedBy) | Gamopanda member ID of the user performing the activity. Use this if the member already exists. |
activityAt | datetime | ✅ | When the activity occurred. Used to determine which aggregation period this log falls into. |
activityId | string | ✅ | Activity Id for this event — e.g. made_a_purchase, visited_store, completed_workout, etc |
uniqueIdentifier | string | ✅ | Unique Identifier for this event — e.g. order_id, transaction_id, session_id, etc |
Optional on create
| Field | Type | Description |
|---|---|---|
activityValue | number | The numeric value of the activity. Required when the streak uses aggregationMethod: sum (e.g. spend amount, steps, calories). Ignored for count streaks. |
ownedBy | object | Inline member upsert payload. Use instead of ownedById to sync the member in the same request. See syncing a member inline below. |
Status
| Field | Type | Default | Description |
|---|---|---|---|
status | enum | live | draft · live · paused. Only live logs are included in aggregation. |
Extra fields returned in the response
After a log is created, the platform enriches the response with several computed fields:
| Field | Description |
|---|---|
streak | The full joined Streak object this log belongs to |
streakProgress | The user's updated Streak Progress record for the current period after this log was processed |
achievedMilestone | The Milestone record crossed by this log entry, if any. null if no milestone was reached. |
nextMilestone | The next Milestone the user is working toward, if any. null if no further milestones exist. |
achievedMilestoneRewardLog | The Reward Log issued when a milestone was crossed by this entry. null if no milestone was reached. |
These fields make the create response self-contained — your backend can read the updated period progress and any earned reward in a single API call without making additional requests.
Handling achievedMilestoneRewardLog
When a milestone threshold is crossed, the platform creates a Reward Log record and returns it as achievedMilestoneRewardLog in the response. At this point the reward log exists but has no coupon code or timestamps yet — your backend is responsible for fulfilling the reward and updating the log.
Reward fulfilment workflow
- Check the response — after
POST /schema/streak_log/record, inspectachievedMilestoneRewardLog. If it is notnull, a milestone was just crossed. - Generate a coupon — call your coupon or voucher system to issue a reward code for this user.
- Update the reward log —
PATCHthe reward log with the coupon code and timestamps:
Code
Reward log lifecycle
| Step | Fields set | Who sets it |
|---|---|---|
| Milestone crossed | milestoneId, linkedSchemaRecordId, ownedById | Platform (automatic) |
| Reward issued | couponCode, rewardIssuedAt, rewardExpiryAt | Your backend |
Syncing a member inline
Instead of managing a separate upsert call to Member before logging activity, you can pass member details directly in the ownedBy field. The platform will create or update the member record automatically as part of processing the log.
Use ownedBy (with externalId) instead of ownedById when you want to sync the user and log activity in a single API call:
Code
The platform resolves the member by externalId, upserts their profile with any supplied fields, and uses the resulting member ID as ownedById for the log.
This is the recommended pattern when logging activity from an order or checkout webhook — you get the member sync and the activity log in one request, reducing latency and the risk of a log being submitted before the member record exists.
| Field | Type | Required | Description |
|---|---|---|---|
externalId | string | ✅ | Your system's unique identifier for this user. Used to match or create the member. |
firstName | string | ❌ | Member's first name |
lastName | string | ❌ | Member's last name |
email | ❌ | Member's email address | |
phoneNumber | phone | ❌ | Member's phone number in E.164 format — e.g. +14155552671 |
See Members for full details on member fields and the E.164 phone number format.
The uniqueIdentifier — preventing duplicates
uniqueIdentifier is your system's unique identifier for the triggering event. The platform uses it to idempotently reject duplicate submissions — if you send the same activityId for the same streakId and ownedById twice, the second request is rejected.
Use whatever identifier uniquely describes the event in your system:
Code
Always pass a stable, unique uniqueIdentifier. If you omit it or pass a generic value, duplicate logs may inflate a user's period progress.
Real-world examples
🛍️ E-commerce — count streak (daily purchase)
A user places an order today. The streak requires one purchase per day (aggregationMethod: count, aggregationTargetValue: 1):
Code
Response — period completed:
Code
☕ Food & Beverage — count streak (daily café visit) — milestone crossed
A user's visit today completes their 7th consecutive day, crossing the first milestone:
Code
Response — milestone crossed:
Code
🏋️ Fitness — sum streak (weekly steps) — period completed
A user's step log pushes them over 70,000 steps for the week, completing the weekly period:
Code
Response — period completed:
Code
Who can create streak logs
Streak Logs are created by your backend server. End users have no write access to this resource.
Code
Access & permissions
| Caller | Allowed operations | Notes |
|---|---|---|
| Admin | CREATE · GET · LIST | Non-editable, Cannot be deleted |
| End user | (none) | No direct access |
| Guest user | (none) | Not accessible |
Streak Logs cannot be updated or deleted. Once submitted, a log entry is permanent. To correct a mistake, contact support.
Related resources
| Resource | Description |
|---|---|
| Streak | The parent streak that defines the rules for aggregation and period length |
| Streak Progress | The running summary of a user's progress per period, updated after each log |
| Milestone | Reward checkpoints that fire when streak length crosses a target |
| Reward Log | Reward entries automatically created when a milestone is crossed |
| Member | The end user (ownedById) whose progress is updated by this log |
API reference
See the API Reference for full request/response schemas and interactive examples for:
POST /schema/streak_log/record— create a streak logGET /schema/streak_log/record— list streak logsGET /schema/streak_log/record/{id}— get a streak log by ID