Is it possible to disable certain built-in xAPI Statements being sent to a LRS?

Jan 18, 2022

We are currently trialing Storyline 360 ( but have been using Storyline since v1) and found an unusual issue when publishing to xAPI in regards to a particular verb statement it sends multiple times on every single slide viewed.

My company currently uses CSOD (Cornerstone On-Demand) for our LMS and LRS. 

While viewing an xAPI course uploaded to CSOD we open up the Developer Tools panel then the Network tab in the latest Chrome browser. Then we can see the xAPI statements being sent to the LRS on CSOD.

But one xAPI verb statement returns a 403 status every time it's sent to the LRS and that statement is sent something like 6 or 7 times PER SLIDE viewed.
That verb is: leave


Here is a list of xAPI verbs that CSOD can accept from an xAPI package:

As you can see "leave" is not one of the supported verbs. The response from the LRS says as much. ""This verb 'http:\/\/\/schema\/1.0\/leave' is not a supported verb. Please check our supported verbs on the Online Help""

Looking deeper in to the payload of the statement in the Network tab, verb "left" is being used with: in the bootstrapper.min.js file.

Is it possible to disable certain statements from being sent to the LRS, without having to manually edit the published  bootstrapper.min.js file so that statement isn't sent automatically?

10 Replies
Shawn Lalla


I understand that a request has been submitted for this feature. I'm unsure what that feature update entails and how much control developers have to send xAPI statements when they choose to do so without having unnecessary built-in statements sent to the LRS. Consideration needs to be made that SaaS LRS's charge for each and every xAPI statement and if Articulate seems to think that sending built-in statements such as "Experienced" (for example) to the LRS for each and every single slide, then we have a problem here. Sending of xAPI statements needs to be controlled by the developer and not by Storyline, let's be absolutely crystal clear here. If this feature update doesn't allow developers to have full control over what and when xAPI statements are being sent to the LRS, then this update defeats the purpose. 

Secondly, consider adding a comprehensive list of verbs that are common with tracking user experience and engagement. 

Tom Fowler

Just wanted to add a +100 to this issue. Users are generating over 200 automated statements per experience, when we only actually need to track 5. As Shawn mentions above, this comes at a cost to your customers wanting to use this functionality that goes far beyond a subscription to 360. Additionally, if we don't intend to use the data, we shouldn't be capturing it from a GDPR perspective, which puts your European Customers in a legally precarious position. Please add this to your roadmap as soon as possible!

Scott Nodine

Thanks to the others above for "putting their two cents in here". It is appreciated!  :)

Since I'm the original author I thought I'd give an update too. The company I work for ended up going with Storyline 360 but we're sticking to SCORM 2004 version 3 for the time being. But we  would really love to start moving towards xAPI using Storyline if we could get amount of automated statements per experience that Storyline generates under control.

So this is still something we are hoping that Articulate can bring to the table as a feature!

Rob Arnts

I would like to see this option added to Storyline. It would be nice if you could set the following:

  • Send standard xApi statements
  • Send only custom statements (built with your own triggers)
  • Send both

It is these types of (relatively) small adjustments that customers need to actually choose a new standard (xApi). Make real insights possible instead of passed/complete only.

Olivier C

I would like to add another vote for this feature.

There is a lot of 'noise' in the standard statements that are sent to the LRS by default. While it may cover some common ground, it's not usable for every situation. When you have to resort to custom statements, the standard statements are mainly in the way, since they are often reporting about the same events that you wrote custom statements for.

The solution mentioned above (send standard, send custom or both) would be a big help. Even better would be if you could choose which standard statements to send. (so provide a list of the standard statements with checkmarks).
And if we can dream: templates to customize the standard statements and their trigger would be great!