Stay in Sync with SCORM Cloud Registration Records

When integrating with SCORM Cloud, keeping your local system updated with learner progress and completion statuses is critical. There are two primary ways to keep your local records in sync with SCORM Cloud: configuring Postbacks (webhooks) for real-time push updates, and implementing a Sync Job to periodically pull updated records.

While postbacks are the most common approach, implementing a sync job is highly recommended—even if you already use postbacks—as a reliable fallback to catch up on any updates missed during a system outage or extended maintenance.

Method 1: Configuring Postbacks

The primary and most common method to keep your system up to date is by leveraging Registration Postbacks. With postbacks configured, SCORM Cloud acts as a webhook, automatically making an HTTP POST request to your designated endpoint anytime a registration record is updated.

Key Benefits of Postbacks:

• Real-Time Updates: Learner progress is sent to your system immediately as it happens.

• Built-in Retries: SCORM Cloud utilizes a durable work queue. If your system is temporarily down or returns an error, SCORM Cloud will retry sending the postback up to 70 times over a period of approximately 6 to 8 hours.

To enable postbacks in one of your SCORM Cloud applications, simply configure ApiRollupRegistrationPostBackUrl with your URL endpoint to receive POST requests from SCORM Cloud using the SetApplicationConfiguration method. For full technical details on configuring postbacks, authenticating requests, and formatting the JSON payload, please refer to the official Registration Postback Guide.

Method 2: Implementing a Sync Job (GetRegistrations)

The second method to stay in sync is to implement a recurring sync job (or cron job) that pulls registration statuses from SCORM Cloud at regular time intervals using the GetRegistrations API endpoint.

A sync job serves two purposes:

1. Alternative to Postbacks: It is a reliable primary method if your system architecture does not support receiving inbound HTTP POST requests or you do not need real-time progress updates.

2. Crucial Fallback/Catch-up Mechanism: SCORM Cloud’s postback retry period maxes out at around 6 to 8 hours. If your system experiences an outage or a maintenance window longer than this, you will have missed out on some postback updates that SCORM Cloud gave up on trying to deliver. A sync job ensures your system can gracefully "catch up" on any missed data once it comes back online so that no learner progress is lost.

How to Implement a Sync Job

To implement a sync job that pulls updated registrations, your application will need to hit the GetRegistrations endpoint using specific query parameters to filter for recent changes, and page through the results

Step 1: Start by making a GET request to the registrations endpoint: GET [https://cloud.scorm.com/api/v2/registrations]

You must include the following query parameters:

• since = the datetime of your last successful sync job run or the start of your outage / maintenance window

• datetimeFilter = updated

Example: GET /api/v2/registrations?since=2026-09-01T12:00:00Z&datetimeFilter=updated

Step 2: SCORM Cloud's GetRegistrations method returns 10 registrations per page. If more than 10 registrations have been updated since the since date, your initial request will return the first 10 updated registrations, along with a more token.

To get the next page of 10 registrations, you must make another GET request to the /registrations endpoint using only the more query parameter. Do not include the since or datetimeFilter parameters on these subsequent requests.

Example: GET /api/v2/registrations?more={your_more_token}

You will continue making this request in a loop, getting the next 10 registrations using the latest more token provided and updating your local records accordingly.

You will know you have reached the end of the updated registrations list when the API response no longer includes a more token.

Summary Best Practice

For the vast majority of integrations, Postbacks are all you need to effectively keep your local records up to date. The built-in retry mechanisms handle brief periods of downtime seamlessly.

However, we strongly recommend having a sync job script available as a contingency plan. Having the ability to manually trigger a sync job from an arbitrary date ensures that you can reliably "catch up" on registration data following an unexpected outage or a planned maintenance period that exceeds the 6 hour postback retry window.