We have opted for usage based billing for our app. We monitor the usage and bill the merchants on a daily basis. We have Aws based lambda billing service to do that. Our flow is simple we ask the backend about usage charges for each store. then we create the usage charges using billing api in a loop. if any usage charge fails we create a record of it in the backend and we do the manual billing through our admin panel for these charges later.
What we are finding here is our billing service only creates charges for 1st store are for rest there are failed billing records. these are due to this usererror from shopify.
So we capture the relevant data and again create the usage charges manually, this time they work. No changes from our side.
We thought this was due some time based restriction from shopify so we tried creating billing at 1 min interval but that again has no effect, same error.
We looked around on this forum there were few related question but they were mainly saying you forgot to send the right lineitemid hence the error, but thats not our case as we clearly are able to create billing manually with same param just not in a loop though an scheduled billing service.
Thanks for getting in touch - this sounds strange. By any chance would you happen to have a request ID for any of the requests for which ‘invalid ID’ was returned? We can take a look in the logs and investigate - thanks!
Could you clarify where I should find request id, on amazon lambda we have requestid but that shouldn’t be relevant here. On appUsageRecordCreate mutation I only have 2 return objects appUsageRecord and userErrors which only has field and message , which I shared earlier (appUsageRecord comes as null and userError comes as I shared earlier). Or should I send some requestid with my request as part of header, let me know I ll do a quick run on our dev environment and share the results.
Yes that would be correct - the name of the request ID in the response headers when Shopify’s mutation is called/REST call is made would be named the “x-request-id”. We’d typically ask for those x-request-id’s from our response headers as trying find out what happened specifically at runtime can be quite an involved process due to many factors (sheer wealth of the platform data, log retention, and so forth).
We also can’t authenticate partners here on the Shopify Community Forums - which I can acknowledge isn’t ideal - but we can work around this using an x-request-id’s (if you have them).
Feel free to share these though once you get a minute and I can ensure this gets escalate to the team. Thanks!
Got the request ids for you. There were 2 stores with pending billing in the test setup, as expected the first one got through and an AppUsageRecord was created, the second one failed . Next we did the manual billing for the failed request and it got through.
Thanks for those request Id’s! I took a look in the logs - there were a couple of things I noticed.
For the ‘loop failure’ one, What is strange, I noticed in the database, that particular subscriptionLineItemID did not exist at all on the store in question.
It had been mentioned that as part of your Billing service, the backend is asked about usage charges for the store then the usage charge is created.
If the store didn’t have that particular subscriptionLineItemID (a usage plan was not created for the store with appSubscriptionCreate prior) then reasonably we’d expect “message: Invalid id” to be shown when appUsageRecordCreate is passed with that same subscriptionLineItemID.
manual success —> 27288dd6-a43b-4c14-9315-68b16e5354a5 shop_id 2 (which curiously uses the same subscriptionLineItemId used in step 2 from a different store).
From the example request ID’s supplied, it seems that the initial lookup in the process (e.g the backend is asked about usage charges for the store) - is actually pulling subscriptionLineItemId’s that are not created with usage pricing plans on the store.
I mentioned prior that we’re limited in the public forms of how much debug we can do for Partners, but if the above findings do not shed any light for you, and you believe this to be a bug, I would recommend to raise this in our Bug Reporting Form here , select the option for API, and follow the authentication steps.
We can’t guarantee all requests or bugs reported here are answered directly, for I would absolutely encourage you use this option and share as much detail as possible! I hope the above helps.
Thanks for looking it up at your end and sharing your analysis. We wanted to share some further info from our logs for these requests and just wanted a confirmation from your side like appSubscriptionlineItemId, shop and price for these request. If these match then there is definitely a bug in the billing api and we will take it up on the forum you mentioned. If not we would need to further debug it at our end then.
As this is private info, should we send a private message here or any other platform.