Changelog

New/now-visible endpoints in the spec (Library attachments)

We updated the PUT/subscription api document to better reflect the required fields. Before, a handful of fields were marked as required when we actually only require at least 1 of the listed fields to be populated. This change better reflects what the api really requires.

A new VendorName parameter has been added to the List of Invoice Items endpoint making it easier for partners to identify which vendor a given invoice item belongs to. Respective endpoint: https://devx.pax8.com/reference/findpartnerinvoiceitems

Developers can now use the API to filter subscription webhooks by specific Completed Line Item types (e.g., New, Renewal, TrialConvert). This allows for more precise automation of billing and provisioning workflows by listening only for the events that matter most. Learn more about Line Item Types.

We will be only keeping the webhook log entries for 30 days.

The /v1/products/{productUUID}/pricing endpoint will now respond with usage product pricing for any arrears product requests. The response now includes productId and productName to distinguish each of the usage prices.

Originally we had the retry logic attempts match the errorThreshold attribute on Webhooks, but we have now capped that at 3 total attempts. However, if the errorThreshold field is set to lower than 3 that will be the max retry attempt. All other retry and email logic remains the same. See updated docs: Webhook docs

The GET /v1/subscriptions/{subscriptionId} endpoint now includes the new vendorSubscriptionId field. For Microsoft products, this field directly provides the corresponding Microsoft Graph API subscription ID. This enhancement significantly simplifies the process of reconciling subscriptions between Pax8 and Microsoft, enabling more streamlined automation and integration.

Provision requests now support volume commitment terms alongside time only based commitments. Volume commitments allow minimum and maximum volume requirements with flexible units of measure.

There was a mistake on the documents for refresh token lifetime limit. The docs stated this was alive for 1 year, which is not the case. The real lifecycle is 90 days for a refresh token before the user is required to re-authorize the app.