Metering limitations and FAQ

what is metering, in plain english? when a customer buys a saas offer on microsoft marketplace, they usually pay a flat monthly fee but some offers also charge based on actual usage — things like emails sent, api calls made, or gb of data processed this is called metered billing the way it works is simple your platform (the isv's software) keeps track of how much the customer uses, and whenever usage goes over the included amount, it sends a report to microsoft saying "this customer used x units of y thing " microsoft then bills the customer for that extra usage that report is sent through the metering service api and that api has specific rules about how and when you can send those reports the one rule you need to know almost everything about the metering api comes down to one rule 📌 the golden rule you can only send one usage report per customer subscription, per billing metric, per calendar hour if you try to send a second one for the same combination within the same hour, it gets rejected as a duplicate that's it everything else is just a variation of this what does "per subscription + per metric + per hour" actually mean? subscription = one customer's order each order has a unique id metric (dimension) = the thing you're billing for (e g emails sent, api calls, storage gb) each offer can have multiple calendar hour = e g 08 00–08 59 is one hour 09 00 starts a fresh slot so the rule applies to a specific combo of all three change any one of them, and it's a completely separate slot so what can i send? ✅ two reports for different customers — no problem if customer a and customer b both have active subscriptions, you can send a report for both at the exact same time they have different subscription ids, so they're totally independent you could send reports for 100 different customers simultaneously ✅ two reports for different metrics — no problem if your offer has two billing dimensions (say, emails sent and api calls), you can send a report for both in the same minute different metrics = different slots no conflict ✅ two reports for the same customer, same metric, different hours — fine if you send a report for customer a's email usage at 08 55, and then again at 09 05 — that's fine those are two different calendar hours, so they're separate slots ❌ two reports for the same customer, same metric, same hour — rejected if you send a report for customer a's email usage at 08 10, and then another one at 08 45 for the same metric — the second one will be rejected you already filled that slot 💡 the right way to handle this don't send every usage event as it happens instead, collect and add up all the usage within an hour, then send one single report at the end of that hour with the total that's what microsoft recommends too only active subscriptions you can only send usage reports for subscriptions that are currently active microsoft will reject events for subscriptions that are • cancelled / unsubscribed • suspended • still pending activation (pendingfulfillmentstart) the one exception if a customer cancels today, you can still send usage reports for the period before the cancellation — as long as you do it within the 24 hour window common scenarios at a glance situation result why two events for the same order, same meter, 5 min apart (same hour) ❌ rejected same hour — combine into one event two events for the same order, same meter, different hours (e g 8 50 and 9 05) ✅ accepted different hours, no conflict two events for the same order, different meters, same time ✅ accepted different dimensions are independent two events for different orders (subscriptions), same meter, same time ✅ accepted different subscriptions = no conflict at all event for a cancelled or suspended subscription ❌ rejected only active (subscribed) subscriptions accepted https //learn microsoft com/en us/partner center/marketplace offers/marketplace metering service apis