Billing and Utilization Metrics With WAC API

  • Updated on Sep 4, 2025
  • Published on Aug 13, 2025
  • 4 minute(s) read
Prev Next

Billing

Billing occurs through your main Wasabi account (Control Account) and includes storage consumption of your Sub-Accounts. You will receive one bill for your Wasabi account and all your Sub-Accounts. Sub-accounts are not billed individually.

To determine the daily storage and data transfer amount associated with a Sub-Account across all buckets, see GET Utilizations for a Sub-Account.

All Sub-Accounts will be considered within the same billing scope of the Control Account, namely:

  • Sub-Accounts will be invoiced on the same periodicity as the Control Account.

  • Sub-Accounts, once out of trial, will be subject to the same minimums applied to all Wasabi accounts (for example, a 1 TB minimum storage charge).

  • Sub-Account invoices will be “rolled up” into a single control invoice that is charged to the Control Account.

  • Sub-Accounts will follow any restrictions that are incurred by the billing status of the Control Account invoice. For example, object uploads will be disallowed once the Control Account invoice remains unpaid past a grace period.

  • Trial Sub-Accounts will be automatically converted to paying accounts at the end of the Sub-Account trial period. It is possible (via this API) to extend a Sub-Account trial period, but there will be a maximum allowed trial duration that will be set by a Wasabi Sales Representative.

  • At this point in time, once a trial Sub-Account converts to a paying account, it is not possible to put the Sub-Account back into trial. Therefore, it is the responsibility of the user of the Wasabi Account Control API to either:  

    • Delete an unwanted trial Sub-Account before the trial period ends, or

    • Extend the trial period for the Sub-Account before the auto-conversion happens.

Rate Limiting

For security and performance reasons, the Wasabi Account Control API will rate limit the number of requests on a per Wasabi Control Account holder basis against the API methods listed below. These limits are currently:

  • 1000 GET operations/min

  • 100 PUT operations/min

  • 100 POST operations/min

  • 10 DELETE operations/min

Any call rates that exceed these limits will be responded to with a standard “HTTP 429 Too Many Requests” response.

Utilization Metrics

Wasabi calculates usage metrics once per day at both a per-bucket and per-account level. These records are stored indefinitely in our systems and can be retrieved on demand. The metrics captured are:

"NumBillableObjects": 1,"NumBillableDeletedObjects": 1,"RawStorageSizeBytes": 1000000000,"PaddedStorageSizeBytes": 1000000000,"MetadataStorageSizeBytes": 87,"DeletedStorageSizeBytes": 1000000000,"OrphanedStorageSizeBytes": 0,"MinStorageChargeBytes": 106374182313,"NumAPICalls": 18,"UploadBytes": 89349,"DownloadBytes": 36784,"StorageWroteBytes": 62325,"StorageReadBytes": 0,"NumGETCalls": 0,"NumPUTCalls": 2,"NumDELETECalls": 0,"NumLISTCalls": 3,"NumHEADCalls": 0,"DeleteBytes": 0

  • NumBillableObjects — The number of objects that are active (that is, not deleted) associated in the account/bucket as of midnight UTC at the time the calculation was made. This number is the total objects under storage and NOT new objects uploaded that day.

  • NumBillableDeletedObjects — The number of objects that have been deleted, but — due to any minimum object lifetime requirements (typically 90 days) associated with the API developer’s billing plan — these objects are still calculated as part of the API developer’s monthly invoice and will be charged at the same rate as non-deleted objects. This number is the total deleted objects under storage and NOT new objects deleted that day.

  • RawStorageSizeBytes — The number of bytes for all non-deleted objects in the account/bucket. This number is the total objects bytes under storage and NOT new objects uploaded that day.

  • PaddedStorageSizeBytes — The number of bytes for all non-deleted objects in the account/bucket but with the minimum object size restriction enforced, based on the API developer’s billing plan (typically, minimum 4k object size). If you are working with objects all larger than 4k, then PaddedStorageSizeBytes will be the same as RawStorageSizeBytes. This number is the total objects bytes under storage and NOT new objects uploaded that day.

  • MetadataStorageSizeBytes — The number of bytes associated with any metadata about the object that is stored in our databases. This number is normally a very small percentage of total storage and will likely be sub-penny in terms of billable amounts.

  • DeletedStorageSizeBytes — The number of padded bytes for all deleted objects in the account/bucket. This number is the total objects bytes under storage and NOT new objects uploaded that day.

  • NumAPICalls, UploadBytes, DownloadBytes, StorageWroteBytes, and StorageReadBytes — API activity related and reflect activity done between the specified time on that day. That is to say, they are not cumulative across days, like storage metrics are.

  • MinStorageChargeBytes — The number of bytes that a user should be charged because they are under the 1 TB minimum storage requirement.

  • DeleteBytes — The sum of the number of all deleted bytes per account/bucket over the day. This is used to track general delete activity and is not used for any billable events.

Converting Metrics to Charges

The Wasabi Account Control API provides for retrieving sub-invoices for the Sub-Accounts. Sub-invoices are generated at the same time the Control Account invoice is computed (every 30 days) and accounts for all of the business rules outlined above (minimum object lifetime, minimum object size, minimum storage requirements, etc.). Therefore, it is easiest for API developers to simply use this feature when creating chargeable events for the API developer’s customers.

However, if API developers wish to implement their billing mechanism, the following indicates how to compute costs on a per-account basis:

Active Storage Charges

SUM-OVER-BILLING-PERIOD( MAX( ( ( PaddedStorageSizeBytes + MetadataStorageSizeBytes ) / POWER(1024, 3) ), 1024) * ( {partner-rate-per-TB-per-Month-with-Wasabi} / 30 / 1024) )

Deleted Storage Charges

SUM-OVER-BILLING-PERIOD( ( DeletedStorageSizeBytes / POWER(1024, 3) ) * ( {partner-rate-per-TB-per-Month-with-Wasabi} / 30 / 1024) )

Egress Charges

SUM-OVER-BILLING-PERIOD( DownloadBytes * {partner-rate-per-GB-egress} )

The MAX(..., 1024) in the Active Storage Charge is to reflect the minimum required storage business logic (in this case, 1 TB = 1024 GB). A future version of this API will include an additional metric in the Utilization to better reflect the minimum storage requirements.

To reiterate, the algorithms above will not be needed by API developers if they use the existing sub-invoice API endpoints described in the Invoices section. We highly recommend using the existing endpoints so as not to have to duplicate business logic in the API developer client code.