Use this file to discover all available pages before exploring further.
Stateful activities span multiple sessions. The client SDK tracks time per session via heartbeats, and the server records completion when the activity is truly done.
A runId ties all sessions together. The SDK generates one automatically when you call activity.start(), but you can also provide your own. Any unique string works. If your app already has a unique identifier for the activity attempt (e.g. an assignment row ID), pass it as runId directly instead of storing a separate value. On resume, pass the same runId so every heartbeat and the final completion event share the same identifier.
The frontend tracks time per session and orchestrates the student’s workflow (starting, resuming, and submitting answers). But completion must come from the server: across multiple sessions, it’s the only part of the system that has the full picture of the student’s accumulated progress.
const activity = timeback.activity.start({ id: 'lesson-1', name: 'Fractions', course: { subject: 'Math', grade: 3 },})// Your API — persist the runId so you can pass it back on resumeawait saveProgress({ lessonId: 'lesson-1', runId: activity.runId })
See the reference for full parameter documentation including time options and callbacks.
This is the key difference from single-session activities: the student can leave at any point — close the tab, navigate away, or simply stop for the day — without losing their progress. Calling activity.end() flushes the accumulated time but does not record a completion. The activity stays open, ready to be resumed later with the same runId.
await activity.end() // Flushes time, no completion
The frontend always calls activity.end() without metrics. Completion is recorded by the
server.
If your server already tracks time (e.g. from request logs or its own session model), you can disable heartbeats entirely by passing time: false. The client still provides the activity.end() ergonomics, but no TimeSpentEvents are sent.
const activity = timeback.activity.start({ id: 'lesson-1', name: 'Fractions', course: { subject: 'Math', grade: 3 }, runId: progress.runId, time: false,})// No heartbeats during the session — end() closes the activity without sending time dataawait activity.end()
When using time: false, the server must report time via the time parameter in
timeback.activity.record(). Do not use both heartbeats and server-side time — this will
double-count. See the server reference for details.
When a student completes an activity, as determined by your app’s logic, the backend records the result using timeback.activity.record(). This sends an ActivityCompletedEvent to the Caliper API and runs the full pipeline including gradebook and XP.Pass the same runId from the frontend to correlate heartbeats with the completion event.
See the reference for full parameter documentation.
Only include time when the frontend uses time: false. If heartbeats
are active (the default), the platform already has the time data — passing time here would
double-count. See the full server reference
for all parameters.
The runId is the correlation key between frontend heartbeats and backend completion. Save
it to your database as soon as the activity starts.
Use a fresh runId for new attempts after completion
When a student starts a new attempt of a previously completed activity, do not reuse the old
runId. Omit it from activity.start() to generate a fresh one — otherwise new heartbeats
would be incorrectly correlated with the old completion event.
Only call activity.end() without args on the frontend
Completion should come from the backend via timeback.activity.record(). The frontend
should always use activity.end() (no metrics) to flush time data only.