Subscription Components

Delete Prepaid Usage Allocation

DELETE
/subscriptions/{subscription_id}/components/{component_id}/allocations/{allocation_id}.json

Deletes a prepaid usage allocation.

Prepaid Usage components are unique in that their allocations are always additive. In order to reduce a subscription's allocated quantity for a prepaid usage component, each allocation must be destroyed individually via this endpoint.

Credit Scheme

By default, destroying an allocation will generate a service credit on the subscription. This behavior can be modified with the optional credit_scheme parameter on this endpoint. The accepted values are:

  1. none: The allocation will be destroyed and the balances will be updated but no service credit or refund will be created.
  2. credit: The allocation will be destroyed and the balances will be updated and a service credit will be generated. This is also the default behavior if the credit_scheme param is not passed.
  3. refund: The allocation will be destroyed and the balances will be updated and a refund will be issued along with a Credit Note.

Authorization

BasicAuth
AuthorizationBasic <token>

The username is a Maxio Chargify API key. The password is x.

In: header

Path Parameters

subscription_id*integer

The Chargify id of the subscription.

component_id*integer

The Advanced Billing id of the component

allocation_id*integer

The Advanced Billing id of the allocation

Request Body

application/json

credit_scheme*Credit Scheme

Value in

  • "none"
  • "credit"
  • "refund"

Response Body

application/json

curl -X DELETE "https://example.com/subscriptions/0/components/0/allocations/0.json" \  -H "Content-Type: application/json" \  -d '{    "credit_scheme": "none"  }'
Empty

Preview Allocations POST

Previews a potential subscription's **quantity-based** or **on/off** component allocation in the middle of the current billing period. This is useful if you want users to be able to see the effect of a component operation before actually doing it. ## Fine-grained Component Control: Use with multiple `upgrade_charge`s or `downgrade_credits` When the allocation uses multiple different types of `upgrade_charge`s or `downgrade_credit`s, the Allocation is viewed as an Allocation which uses "Fine-Grained Component Control". As a result, the response will not include `direction` and `proration` within the `allocation_preview`, but at the `line_items` and `allocations` level respectfully. See example below for Fine-Grained Component Control response.

Update Prepaid Usage Allocation Expiration Date PUT

Updates the expiration date for a prepaid usage allocation. This expiration date can be changed after the fact to allow for extending or shortening the allocation's active window. In order to change a prepaid usage allocation's expiration date, a PUT call must be made to the allocation's endpoint with a new expiration date. ## Limitations A few limitations exist when changing an allocation's expiration date: - An expiration date can only be changed for an allocation that belongs to a price point with expiration interval options explicitly set. - An expiration date can be changed towards the future with no limitations. - An expiration date can be changed towards the past (essentially expiring it) up to the subscription's current period beginning date.