Problem with stripe.usageRecords.create() since v 6.0.0

[drmrbrewer]

Despite passing a valid si_xxx id into the stripe.usageRecords.create() call exactly as specified in the docs I am now getting an error returned saying "Error: No such subscription item" and also something about invalid request.

The library was recently updated to version 6.0.0 (four days ago), and I myself started using that maybe two days ago. This coincides with when my problems started.

I note that there is a commit called "Merge pull request #453 from stripe/jlomas-fix-usage-records" from four days ago... so some changes were made to usage records API, and this probably broke things?

I've reverted to 5.8.0 and everything is working fine again, so it definitely seems to be a problem with the changes made in 6.0.0.

[brandur-stripe]

Hi there,

Can you paste your code here?

In 6.0.0 we retooled this API (for usage record creation) a little bit to make it more consistent with the rest of the library and to fix a few bugs. Your invocation should now look like this:

stripe.usageRecords.create("si_CspeIL2QYRmDqy", {
  quantity: 100,
  timestamp: 1526632250
}, function(err, usageRecord) {
  // asynchronously called
});

The important part to note is that the subscription item is no longer passed in the standard arguments object and has instead become a position argument to create.

[drmrbrewer]

Aah, yes I was still passing the subscription item via subscription_item: subscriptionItemId in the standard arguments object. I've moved it out as per your emample (and indeed as per the docs... I failed to spot that there had been a change), and it's working again. Thanks.

Could I maybe suggest a slightly more helpful error message, to inform those users (like me) who might get caught out by this breaking change... just detecting that the old-style request has been used, and throwing an error with a message to tell the user to change to the new format? And maybe (in an interim period) accepting both old and new style?

Also, it would be great if there could be a stripe.usageRecords.retrieve("si_CspeIL2QYRmDqy") method, to retrieve the current usage info. At present I am having to get this indirectly from stripe.invoices.retrieveUpcoming(customerId), which is OK but a dedicated method for retrieving usage info would seem to be appropriate.

Thanks again.

[brandur-stripe]

Aah, yes I was still passing the subscription item via subscription_item: subscriptionItemId in the standard arguments object. I've moved it out as per your emample (and indeed as per the docs... I failed to spot that there had been a change), and it's working again. Thanks.

No worries! And sorry about the trouble here — in general we really try to make sure that we get things right the first time and don't have to make changes like this, but the feature was so new and we'd gotten the initial interface wrong that I made an executive decision to change it here.

And by the way, in the future if you ever see that the major version of the library has been bumped, I'd highly recommend just making sure to read the CHANGELOG and try to see if there's anything in there that might look like it's relevant to your purposes. Not saying it necessarily would have saved you here, but it might have made diagnosis for you a little easier.

Could I maybe suggest a slightly more helpful error message, to inform those users (like me) who might get caught out by this breaking change... just detecting that the old-style request has been used, and throwing an error with a message to tell the user to change to the new format? And maybe (in an interim period) accepting both old and new style?

Yeah, that probably would have been a good idea, but we decided not to implement it that way just because the feature was very new and had few users. If we get another report in a similar vein to yours, I'll look into adding that.

Also, it would be great if there could be a stripe.usageRecords.retrieve("si_CspeIL2QYRmDqy") method, to retrieve the current usage info. At present I am having to get this indirectly from stripe.invoices.retrieveUpcoming(customerId), which is OK but a dedicated method for retrieving usage info would seem to be appropriate.

Oh interesting. That's good feedback — thank you!

@alexander-stripe Would you mind passing the above along to the rest of the team?

I'm going to close this out for now, but let us know if you have anymore trouble.

[drmrbrewer]

Thanks, I appreciate the really quick help on this.

feature was very new and had few users

This is surprising. With metered billing, how are other users updating the user record to record chargeable usage? Manually via the dashboard? Or is metered billing just not very common?

ever see that the major version of the library has been bumped

Yep this one slipped through in amongst a whole bunch of other package version updates :)

And thanks for at least considering usageRecords.retrieve()... IMHO it would be a nice addition.

[brandur-stripe]

This is surprising. With metered billing, how are other users updating the user record to record chargeable usage? Manually via the dashboard? Or is metered billing just not very common?

It's just not super common yet. The feature is just a few weeks old.

[drmrbrewer]

Metered billing is that new, or the API call is? I've only been using stripe and the API for a couple of weeks so I'm.just curious.

[brandur-stripe]

Metered billing is that new, or the API call is? I've only been using stripe and the API for a couple of weeks so I'm.just curious.

It's both, although my sense of time was a little off. Here's the blog post announcing it dated April 5th.