The information on this page is now deprecated, along with the content.update webhook. A replacement webhook system is being released to support content changes, contact Go1 support for more information.
Get notified when Go1 content has been updated, so you can update the metadata presented for that course within your application.
This article explores how to utilise the Content Update Webhook to get notified and action new updates to the Go1 library. The Go1 library is continually evolving and being updated by our content providers in the following ways:
The content_update webhook event is triggered whenever content that you can see within your Go1 portal changes. When these updates occur, if you have previously synced content to your application, it is your responsibility to handle the content updates in an elegant way to provide the best user experience for your customers and users. We'll provide some examples and best practices for how to action content updates in your application in greater detail in the implementation steps below.
Content material updates when working with Go1's SCORM files
If you have chosen to retrieve Go1 learning objects as SCORM files (see. Download and play content as SCORM), each piece of Go1 content has a 1:1 relationship with our SCORM wrapper package. The SCORM wrapper is simply a window to the content materials that reside on Go1's servers. This means that when content materials are updated by Go1 content providers, the changes will be automatically reflected through the existing SCORM files you have obtained from Go1, there is no need for you to resync SCORM packages. You are only required to update the content metadata if this is changed by the provider - eg. the title, description, images, etc.
To successfully set up and utilise the content update webhook, we'll walk through the following implementation steps below.
How the content update webhook works
The content_update webhook payload event is triggered whenever content within the entire Go1 library is updated. This includes new content added, content is removed, content is edited.
Whenever one of these actions happen across the entire library, Go1 will fire a payload to the configured webhook containing a list of lo-ids that have been affected.
Example payload:
{ "type": "content_update", "fired_at": "2020-08-17T06:11:29+0000", "data": { "loIds": [ 22646286, 22906633, 22911740, 23083834, 23962354, 23965684, 23995342, 24003022, 24020976 ] } }
These notifications are ignorant of the content that you may have synced to your application. Additionally, these notifications are ignorant of the type of update that has occurred to the content. It could be that new content is now available, content metadata have been updated, or content has been removed entirely. The receiver must work out what actually happened to each learning object sent in the payload. We'll discuss this in greater detail in the implementation steps below.
Before setting up the webhook, you will need a establish a URL in your application that can receive payloads from Go1 webhooks. This URL location will be configured when you initially create the webhook - see how this works below.
To create the content_update webhook, make a POST request to the https://api.go1.com/v2/webhooks, specifying the following values in the body:
Here is an example request:
curl --location --request POST 'https://api.go1.com/v2/webhooks' \ --header 'Authorization:<CUSTOMER_ACCESS_TOKEN>' \ --header 'Content-Type: application/json' \ --data-raw '{ "enrollment_create": false, "enrollment_delete": false, "enrollment_update": false, "lo_create": false, "lo_delete": false, "lo_update": false, "enabled": true, "secret_key": "", "url": "<YOUR LOCATION URL TO RECEIVE PAYLOADS FROM GO1>", "user_create": false, "user_delete": false, "user_update": false, "content_update": true, "content_decommission": false }'
A successful response will return the created webhook ID. The webhook ID can be used later to view, update or delete the webhook - see the Webhook API reference to learn more about these functions.
With the webhook created, you are now ready to receive payload events to the URL you have configured.
When new content is added, content is removed or content is edited, Go1 will trigger a content_update event that will be sent to your configured webhook URL. The payload will contain a list of LO-ID (learning object ids) for the content that has been updated.
{ "type": "content_update", "fired_at": "2021-03-31T00:35:29+0000", "data": { "loIds": [ 22646286, 22906633, 22911740, 24020976 ] } }
Within the payload, make note of the following:
You'll note that the content update payload does not specify what updates took place to the content. The payload will include a list of learning object id's - you will need to validate the type of update that took place.
To do this, you can query the Learning Object by passing in the LO-ID to the API via a GET request to /v2/learning-objects/<LO-ID>. The response from the API will help you determine what has happened to the learning object in question.
Ultimately how you choose to action these updates in your application is up to you. To provide the best user experience to your customers and users, we recommend the below actions: