Usages

Record, list, read, change and delete the usage that Exsited bills on metered order lines.

A usage records how much of a metered item a customer used in a billing period, against one order line. This area records usages one at a time or several at once, and lists, reads, changes and deletes them. It has 6 endpoints, and every SDK supports all of them.

At a glance

Endpoint	Method	Path	What it does
List usages	GET	/usages	Lists recorded usages, one page at a time.
Create usages	POST	/usages	Records one usage, or several in one call, against a metered order line.
Retrieve a usage	GET	/usages/{usage_id}	Returns one usage, under usage.
Delete a usage	DELETE	/usages/{usage_id}	Deletes a usage and returns no content.
Update a usage	PATCH	/usages/{usage_id}	Changes some of a usage’s fields and returns a reference to it.
Replace a usage	PUT	/usages/{usage_id}	Replaces a usage’s quantity, times and custom attributes and returns a reference to it.

Before you call

Register your API credentials once when your app starts, as shown in Authentication. Every SDK sample on these pages then gets its client in one line. With cURL, send the access token in an Authorization header: Authorization: Bearer $ACCESS_TOKEN.

Things to know

• A usage belongs to a metered order line. charge_item_id is the id of an order line whose item is charged as METERED.
• charging_period is two dates joined by a hyphen. It runs from the order’s order_start_date to the day before its next_billing_from_date, such as 2026-10-01-2026-10-31.
• One usage goes under usage, several under usages. A list sent under usage returns 400. For several, the response lists each one under usages.success or usages.failed.
• Updates return a reference, not the usage. Update a usage and Replace a usage return only the usage’s id and href under usage; retrieve the usage again to see the new values.
• The listing pages by cursor. Send limit, then pass pagination.next_cursor as cursor while pagination.has_more is true.