Welcome to the v1 API reference for the Zuora Billing, Payments, and Platform!
To learn about the common use cases of the Zuora v1 API, check out the API Tutorials.
Important: This API Reference only showcases the parameters, fields, and behaviors available for the latest API minor version (2025-08-12). For more information about Zuora API versions, see API versions and API upgrades.
We recommend that you upgrade to the latest API version to take advantage of the latest Zuora capabilities. For instructions about upgrading the API version, see API upgrade guide.
Try the v1 API in our Postman collection:
Some of our older APIs are no longer recommended but still available, not affecting any existing integration. To find related API documentation, see Older API Reference.
More OpenAPI specification options
To support your integration with our OpenAPI specifications, whether using in-house solutions or third-party tools, we provide the following resources:
Order-to-Cash operations (detailed): Download Order-to-Cash OpenAPI spec, which includes full descriptions and examples
Full OpenAPI spec (compact): Download Compact OpenAPI Spec, which covers the entire API set without descriptions or samples.
If you need a different API specification beyond the options above, contact Zuora Global Support, and we will provide a custom spec tailored to your needs.
Zuora recommends that you use OAuth v2.0 to authenticate to the Zuora REST API.
You must first create an OAuth client in the Zuora UI before using the Create an OAuth token operation to create an OAuth token. See Authentication for more information.
The Commerce APIs provide access to product catalog, plans, charges, and order management functionality in Zuora. These endpoints are used to create, update, and query product rate plans, charges, and dynamic pricing details that drive subscription and billing behavior.
In a typical use case, the Commerce APIs are called to provision new products or plans in the catalog, configure dimensional pricing, or submit orders that create and modify subscriptions.
Changes made with these APIs affect the product catalog and active subscriptions, depending on the endpoint. Catalog changes update future subscription behavior, while order operations directly impact customer subscriptions in real time.'
Some operations in this section are similar to each other, but are provided for different use scenarios. You should choose the one that best suits your needs.
For example, the Retrieve an account operation retrieves the basic information of an account, such as bill-to and sold-to contacts, billing and payments setup information, and metrics data for the account.
The Retrieve an account summary operation returns the more detailed information of an account, such as bill-to and sold-to contacts, subscriptions, invoices, payments, and usages associated with this account.
A contact defines the customer who holds an account or who is otherwise a person to contact about an account. An account requires a contact for the BillToId and SoldToId fields before the account can be active.
Orders are contractual agreements between merchants and customers.
You can create multiple subscriptions and subscription amendments at once in a single order. All the operations on subscriptions in orders are done by order actions. You can also create order line items to support your non-subscription based business models.
Zuora calculates order delta metrics when orders take place. You can retrieve order delta metrics and measure billed and unbilled amounts by order.
For more information about Orders, see Overview Of Orders. To learn how orders interacts with billing accounts, subscriptions, and product catalog, see Zuora object model.
Use order line item to launch non-subscription and unified monetization business models in Zuora, in addition to subscription business models. For more information about order line items, see Order Line Items.
Fulfillments are subordinate objects attached to their related order line item. Fulfillment items are subordinate objects attached to their related fulfillment.
A Ramp is a time container to associate with rate plan charges in your subscription. Inside the Ramp, you can further define a set of Ramp Intervals (time-based periods) where products or pricing can change. These periods are sub time containers to enable you to report out-of-the-box metrics based on Ramp Intervals.
Notes: You must have both the Ramps feature and Orders feature enabled for your tenant to use the Ramps operations.
A subscription is a product or service that has recurring charges, such as a monthly flat fee or charges based on usage. Subscriptions can also include one-time charges, such as activation fees. Every subscription must be associated with an account. At least one active account must exist before any subscriptions can be created.
An omnichannel subscription is a subscription originating from external and source systems, such as the Apple App Store, Google Play Store, and Roku Store.
To create, update, delete, or retrieve an omnichannel subscription, you must turn on the Omni-Channel Subscription feature. For more information, see Omni-Channel Subscription.
A rate plan is part of a subscription or an amendment to a subscription, and it comes from a product rate plan. Like a product and its product rate plans, a subscription can have one or more rate plans. Rate plans are sometimes called subscription rate plans. Rate plans that are part of an amendment are sometimes called amendment rate plans.
Rate plans represent a price or a collection of prices for a service you sell. An individual rate plan contains all charges specific to a particular subscription.
A commitment represents a minimum or maximum spend amount a customer is obligated to pay within a spend period, compared with customer's actual fees incurred in connection with customer's accounts and their use of applicable products. The Commitments API allows you to retrieve details of the commitments a customer has.
The Prepaid with Drawdown feature is a pricing model for consumption-based services, such as data storage. Under this model, customers pay upfront to receive a number of units, usually for a period of time like a month or a year. Then they consume against that prepayment balance in a use-it-or-lose-it fashion, with a possibility of topping up more units or being charged for any overage. This model strikes a balance between upfront commitment and the pure pay-as-you-go pricing models. For more information, see Prepaid with Drawdown.
Consumption of a billable service or resource (such as database storage space or bundles of emails sent) provides the basis for some charge models - simple usage, tiered pricing, or volume pricing. To make this work, usage must be tracked in the system and usage charges must be calculated and invoiced. Usage is always billed in arrears - for example, you might bill customers in February for their January usage. Usage can be billed on a recurring monthly, quarterly, semi-annual, or annual basis.
The Zuora Mediation APIs provide a comprehensive set of endpoints to manage, test, run, and monitor usage meters. These APIs support actions such as running or testing specific meter versions, importing and exporting meter configurations, managing input files, performing event store operations, and ingesting usage data in real time via streaming. All APIs follow a consistent response structure to simplify integration and error handling. Use these APIs to automate and streamline your usage processing pipeline—from data ingestion to transformation and billing.
Delivery Adjustments are used to handle end customer delivery complaints for the Delivery Pricing charge model. For more information, see Delivery Adjustments.
Creates a standalone invoice for selling physical goods, services or other items on a non-recurring basis to your subscription customers.
To use this operation, you must have the Modify Invoice and at least one of the Create Standalone Invoice With Product Catalog or Create Standalone Invoice Without Product Catalog user permissions. See Billing Roles for more information.
Security
bearerAuth
Headers
Idempotency-Keystring<= 255 characters
Specify a unique idempotency key if you want to perform an idempotent POST or PATCH request. Do not use this header in other request types.
With this header specified, the Zuora server can identify subsequent retries of the same request using this value, which prevents the same operation from being performed multiple times by accident.
Accept-Encodingstring
Include the Accept-Encoding: gzip header to compress responses as a gzipped file. It can significantly reduce the bandwidth required for a response.
If specified, Zuora automatically compresses responses that contain over 1000 bytes of data, and the response contains a Content-Encoding header with the compression algorithm so that your client can decompress it.
Content-Encodingstring
Include the Content-Encoding: gzip header to compress a request. With this header specified, you should upload a gzipped file for the request payload instead of sending the JSON payload.
Zuora-Track-Idstring<= 64 characters
A custom identifier for tracing the API call. If you set a value for this header, Zuora returns the same value in the response headers. This header enables you to associate your system process identifiers with Zuora API calls, to assist with troubleshooting in the event of an issue.
The value of this field must use the US-ASCII character set and must not include any of the following characters: colon (:), semicolon (;), double quote ("), and quote (').
Zuora-Entity-Idsstring
An entity ID. If you have Zuora Multi-entity enabled and the OAuth token is valid for more than one entity, you must use this header to specify which entity to perform the operation in. If the OAuth token is only valid for a single entity, or you do not have Zuora Multi-entity enabled, you should not set this header.
Zuora-Org-Idsstring
Comma separated IDs. If you have Zuora Multi-Org enabled, you can use this header to specify which orgs to perform the operation in. If you do not have Zuora Multi-Org enabled, you should not set this header.
The IDs must be a sub-set of the user's accessible orgs. If you specify an org that the user does not have access to, the operation fails. This header is important in Multi-Org (MO) setups because it defines the organization context under which the API should operate—mainly used for read access or data visibility filtering. If the header is not set, the operation is performed in scope of the user's accessible orgs.
Zuora-Versionstring
The minor API version.
For a list of available minor versions, see API upgrades.
Bodyapplication/jsonrequired
accountIdstring
The ID of the account associated with the invoice.
You must specify either accountNumber or accountId for a customer account. If both of them are specified, they must refer to the same customer account.
Example: "8ad09be48db5aba7018db604776d4854"
accountNumberstring
The Number of the account associated with the invoice. You must specify either accountNumber or accountId for a customer account. If both of them are specified, they must refer to the same customer account.
autoPayboolean
Whether invoices are automatically picked up for processing in the corresponding payment run.
Default false
billToContactobject(Contact)
Container for bill-to, sold-to, or ship-to contact information. A new Contact will be created under the invoice owner account.
Note: If you have the Flexible Billing Attributes feature disabled, this field is unavailable in the request body.
billToContactIdstring
The ID of the bill-to contact associated with the invoice. This field is mutually exclusive with the billToContact field.
Note: If you have the Flexible Billing Attributes feature disabled, this field is unavailable in the request body.
commentsstring
Comments about the invoice.
currencystring
The code of a currency as defined in Billing Settings through the Zuora UI.
If you do not specify a currency during standalone invoice creation, the default account currency is applied. The currency that you specify in the request must be configured and activated in Billing Settings. Note: This field is available only if you have the Multiple Currencies feature enabled.
customRatesArray of objects(customRates)<= 2 items
It contains Home currency and Reporting currency custom rates currencies. The maximum number of items is 2 (you can pass the Home currency item or Reporting currency item or both).
Note:
This field is available only if you are on the latest Zuora API minor version, or you set the Zuora-Version request header to 224.0 or a later available version.
You cannot set the custom rates, if both the Automatically include additional Currency Conversion information in data source exports option and Fx data feature are enabled.
Invoice, InvoiceItem, and TaxationItem will utilize the provided custom Fx rate to convert amounts from the transactional currency to the home currency.
dueDatestring(date)
The date by which the payment for this invoice is due, in yyyy-mm-dd format.
invoiceDatestring(date)required
The date that appears on the invoice being created, in yyyy-mm-dd format. The value cannot fall in a closed accounting period.
Example: "2024-07-30"
invoiceItemsArray of objects(invoiceItemFieldsCustom)
Container for invoice items. The maximum number of invoice items is 1,000.
You must have corresponding billing permissions to create invoice items from existing product rate plan charges or new charges. For more information about billing permissions, see Billing Roles.
To create an invoice item from an existing charge, you must have the Create Standalone Invoice With Product Catalog permission and specify the charge ID in the productRatePlanChargeId field.
To create an invoice item from a new charge, you must have the Create Standalone Invoice Without Product Catalog permission without specifying the productRatePlanChargeId field.
Note: For the "Create a standalone invoice" and "Create standalone invoices" operations, note the following:
If tax has been calculated by an external tax engine, you need to create a standalone invoice with both invoiceItems and taxItems. The taxItems corresponds to the tax information processed by this external tax engine. In this case, you should not specify the taxMode and taxCode nested fields of the invoiceItems field. Instead, you need to specify the taxMode and taxCode nested fields of the taxItems field. You need to specify the taxMode field as TaxExclusive.
If tax has not been calculated by an external tax engine, you can create a standalone invoice only with invoiceItems, and decide whether Zuora includes the tax in the quoted charge price and invoice item by specifying the taxMode nested field of the invoiceItems field as either TaxExclusive or TaxInclusive. Meanwhile, you need to specify the taxCode field, indicating the charge price and invoice item are taxable.
A customized invoice number with the following format requirements:
Max length: 32 characters
Acceptable characters: a-z,A-Z,0-9,-,_,
Purely numerical prefixes or prefixes ending with a number are supported for standalone invoices. For example, you can use 202310000300, 2003, INV202310000300, or 2023-09-100009785 as invoice numbers.
The ID or name of the payment term associated with the invoice. For example, Net 30. The payment term determines the due dates of invoices.
Note: If you have the Flexible Billing Attributes feature disabled, this field is unavailable in the request body.
sequenceSetstring
The ID or name of the sequence set associated with the invoice.
Note: If you have the Flexible Billing Attributes feature disabled, this field is unavailable in the request body.
shipToContactobject(Contact)
Container for bill-to, sold-to, or ship-to contact information. A new Contact will be created under the invoice owner account.
Note: If you have the Flexible Billing Attributes feature disabled, this field is unavailable in the request body.
shipToContactIdstring
The ID of the ship-to contact associated with the invoice. This field is mutually exclusive with the shipToContact field. Note: If you have the Flexible Billing Attributes feature disabled, this field is unavailable in the request body.
shipToSameAsBillToboolean
Whether the ship-to contact and bill-to contact are the same entity. This field is mutually exclusive with the shipToContact and shipToContactId fields.
The created invoice has the same bill-to contact and ship-to contact entity only when all the following conditions are met in the request body:
This field is set to true.
A bill-to contact or bill-to contact ID is specified.
Neither ship-to contact nor ship-to contact ID is specified.
Note: If you have the Flexible Billing Attributes feature disabled, this field is unavailable in the request body.
Default false
soldToContactobject(Contact)
Container for bill-to, sold-to, or ship-to contact information. A new Contact will be created under the invoice owner account.
Note: If you have the Flexible Billing Attributes feature disabled, this field is unavailable in the request body.
soldToContactIdstring
The ID of the sold-to contact associated with the invoice. This field is mutually exclusive with the soldToContact field.
Note: If you have the Flexible Billing Attributes feature disabled, this field is unavailable in the request body.
soldToSameAsBillToboolean
Whether the sold-to contact and bill-to contact are the same entity. This field is mutually exclusive with the soldToContact and soldToContactId fields.
The created invoice has the same bill-to contact and sold-to contact entity only when all the following conditions are met in the request body:
This field is set to true.
A bill-to contact or bill-to contact ID is specified.
Neither sold-to contact nor sold-to contact ID is specified.
Note: If you have the Flexible Billing Attributes feature disabled, this field is unavailable in the request body.
Default false
statusstring
The status of invoice. By default, the invoice status is Draft.
When creating an invoice, if you set this field to Posted, the invoice is created and posted directly.
Default "Draft"
Enum"Draft""Posted"
templateIdstring
The ID of the invoice template associated with the invoice.
Note: If you have the Flexible Billing Attributes feature disabled, this field is unavailable in the request body.
transferredToAccountingstring
Enum"Processing""Error""Ignore""Yes""No"
IntegrationId__NSstring<= 255 characters
ID of the corresponding object in NetSuite. Only available if you have installed the Zuora Connector for NetSuite.
IntegrationStatus__NSstring<= 255 characters
Status of the invoice's synchronization with NetSuite. Only available if you have installed the Zuora Connector for NetSuite.
SyncDate__NSstring<= 255 characters
Date when the invoice was synchronized with NetSuite. Only available if you have installed the Zuora Connector for NetSuite.
property name*anyadditional property
Custom fields of the Invoice object. The name of each custom field has the form customField__c. Custom field names are case sensitive. See Custom Fields for more information.
This header is returned if you specify the Accept-Encoding: gzip request header and the response contains over 1000 bytes of data.
Note that only the following MIME types support gzipped responses:
application/json
application/xml
text/html
text/csv
text/plain
RateLimit-Limitstring
The request limit quota for the time window closest to exhaustion. See rate limits for more information.
RateLimit-Remainingnumber
The number of requests remaining in the time window closest to quota exhaustion. See rate limits for more information.
RateLimit-Resetnumber
The number of seconds until the quota resets for the time window closest to quota exhaustion. See rate limits for more information.
Zuora-Request-Idstring= 36 characters
The Zuora internal identifier of the API call. You cannot control the value of this header.
Zuora-Track-Idstring<= 64 characters
A custom identifier for tracing the API call. If you specified a tracing identifier in the request headers, Zuora returns the same tracing identifier. Otherwise, Zuora does not set this header.
Concurrency-Limit-Typestring
The type of the concurrency limit, which can be Default, High-volume transactions, or Object Query.
The ID of the customer account associated with the invoice.
adjustmentAmountnumber
The amount of the invoice adjustments associated with the invoice.
amountnumber
The total amount of the invoice.
amountWithoutTaxnumber
The invoice amount excluding tax.
autoPayboolean
Whether invoices are automatically picked up for processing in the corresponding payment run.
balancenumber
The remaining balance of the invoice after all payments, adjustments, and refunds are applied.
billRunIdstring
The id of bill run if the invoice is generated by a bill run.
billToContactIdstring or null
The ID of the bill-to contact associated with the invoice.
billToContactSnapshotIdstring
The ID of the bill-to contact snapshot associated with the invoice.
commentsstring
Comments about the invoice.
createdByIdstring
The user ID of the person who created the invoice. If a bill run generated the invoice, then the value is the user ID of person who created the bill run.
createdDatestring(date-time)
The date and time when the invoice was created, in yyyy-mm-dd hh:mm:ss format. For example, 2017-03-01 15:31:10.
creditBalanceAdjustmentAmountnumber
The currency amount of the adjustment applied to the customer's credit balance.
Note: This field is only available if you have the Credit Balance feature enabled and the Invoice Settlement feature disabled.
creditMemoAmountnumber
The currency amount of all credit memos applied to this invoice.
Note: This field is only available if you have Invoice Settlement enabled. The Invoice Settlement feature is generally available as of Zuora Billing Release 296 (March 2021). This feature includes Unapplied Payments, Credit and Debit Memo, and Invoice Item Settlement. If you want to enable Invoice Settlement, see Invoice Settlement Enablement and Checklist Guide for more information.
currencystring or null
The currency of the invoice.
Note: By default, the currency on a billing document matches the default currency set on the associated account. However, Zuora now offers a Multiple Currencies feature to support different currencies for billing documents, allowing flexibility beyond the account-level currency. For more information, see Multiple Currency.
discountnumber
the invoice discount amount.
dueDatestring(date)
The date by which the payment for this invoice is due, in yyyy-mm-dd format.
einvoiceErrorCodestring
The error code when status is "Failed". This code can either be a Zuora-generated error code or one returned by a third-party e-invoice vendor.
einvoiceErrorMessagestring
The error message when status is "Failed". This message can either be a Zuora-generated error code or one returned by a third-party e-invoice vendor.
einvoiceFileIdstring
The ID of the e-invoice file.
einvoiceStatusstring
The status of the e-invoice file generation for the invoice.
If e-invoicing file generation succeeds, this field is either Generated or Success, and both the error code and message are empty, and the eInvoiceField fieldstores the ID of the generated e-inoice file.
If the responses from tax vendors such as Sovos or Avalara are taking too long, this field becomes RetrieveTimeOut. Once the vendor responds successfully, you can use the 'Resync E-Invoice Status' action to update the status automatically. You can view these updates in System Health telemetry.
If a failure occurs during e-invoice file generation, this field is Failed and error code and an error message are returned respectively in the einvoiceErrorCode and einvoiceErrorMessage fields.
If e-invoice file generation conditionally succeeds, this field is ConditionalSuccess and an error code and an error message are returned respectively in the einvoiceErrorCode and einvoiceErrorMessage fields.
If the e-invoice file has been approved by the tax authority, this field is ApprovedByAuthority. The next status will be either Success or Rejected.
If the e-invoice file has been rejected by the government, this field is Rejected. You cannot resend this e-invoice; you must create a new invoice instead. Note: This field is available only if you have the E-Invoicing feature in Early Adopter phase enabled.
Note: This field is available only when the Multi-Org feature is enabled.
paymentAmountnumber
The amount of payments applied to the invoice.
paymentTermstring or null
The name of payment term associated with the invoice.
postedBystring
The user ID of the person who moved the invoice to Posted status.
postedDatestring(date)
The date when the invoice was posted.
refundAmountnumber
Specifies the amount of a refund that was applied against an earlier payment on the invoice.
sequenceSetIdstring or null
The ID of the sequence set associated with the invoice.
communicationProfileIdstring or null
The ID of the communication profile associated with the invoice.
shipToContactIdstring or null
The ID of the ship-to contact associated with the invoice.
shipToContactSnapshotIdstring
The ID of the ship-to contact snapshot associated with the invoice.
soldToContactIdstring or null
The ID of the sold-to contact associated with the invoice.
soldToContactSnapshotIdstring
The ID of the sold-to contact snapshot associated with the invoice.
sourcestring
The source of the invoice.
Enum"BillRun""API""ApiSubscribe""ApiAmend"
sourceIdstring
The ID of the invoice source. If an invoice is generated from a bill run, the value is the number of the corresponding bill run.Otherwise, the value is null.
Returns true if the request was processed successfully.
targetDatestring(date)
This date is used to determine which charges are to be billed. All charges that are to be billed on this date or prior will be included in this bill run.
taxAmountnumber
The amount of taxation.
taxExemptAmountnumber
The calculated tax amount excluded due to the exemption.
taxMessagestring or null
The message that the tax engine return if it calculates the taxes of this invoice fails.
taxStatusstring
The status that the tax engine return after it calculates the taxes of this invoice.
Note: This field is only applicable to tax calculation by third-party tax engines. The Voided status indicates that the tax transaction is successfully canceled on the tax vendor's side. If a tax transaction was successfully committed to the third-party tax engine but the invoice failed to post, Zuora automatically detects the issue and voids the tax transaction on the vendor's side.
If you have the Flexible Billing Attributes feature enabled, the value of this field depends on the configuration of the invoice template.
If you specify an invoice template at the subscription level, the value of this field is automatically populated from the corresponding subscription.
If you do not specify any invoice template at the subscription level, the value of this field is automatically populated from the corresponding account.
If you have the Flexible Billing Attributes feature disabled, the value of this field is null.
transferredToAccountingstring
Whether the invoice was transferred to an external accounting system.
Enum"Processing""Error""Ignore""Yes""No"
updatedByIdstring
The ID of the Zuora user who last updated the invoice.
updatedDatestring(date-time)
The date when the invoice was last updated.
IntegrationId__NSstring<= 255 characters
ID of the corresponding object in NetSuite. Only available if you have installed the Zuora Connector for NetSuite.
IntegrationStatus__NSstring<= 255 characters
Status of the invoice's synchronization with NetSuite. Only available if you have installed the Zuora Connector for NetSuite.
SyncDate__NSstring<= 255 characters
Date when the invoice was synchronized with NetSuite. Only available if you have installed the Zuora Connector for NetSuite.
property name*anyadditional property
Custom fields of the Invoice object. The name of each custom field has the form customField__c. Custom field names are case sensitive. See Custom Fields for more information.
You can update a maximum of 50 invoices by one call.
Security
bearerAuth
Headers
Accept-Encodingstring
Include the Accept-Encoding: gzip header to compress responses as a gzipped file. It can significantly reduce the bandwidth required for a response.
If specified, Zuora automatically compresses responses that contain over 1000 bytes of data, and the response contains a Content-Encoding header with the compression algorithm so that your client can decompress it.
Content-Encodingstring
Include the Content-Encoding: gzip header to compress a request. With this header specified, you should upload a gzipped file for the request payload instead of sending the JSON payload.
Zuora-Track-Idstring<= 64 characters
A custom identifier for tracing the API call. If you set a value for this header, Zuora returns the same value in the response headers. This header enables you to associate your system process identifiers with Zuora API calls, to assist with troubleshooting in the event of an issue.
The value of this field must use the US-ASCII character set and must not include any of the following characters: colon (:), semicolon (;), double quote ("), and quote (').
Zuora-Entity-Idsstring
An entity ID. If you have Zuora Multi-entity enabled and the OAuth token is valid for more than one entity, you must use this header to specify which entity to perform the operation in. If the OAuth token is only valid for a single entity, or you do not have Zuora Multi-entity enabled, you should not set this header.
Zuora-Org-Idsstring
Comma separated IDs. If you have Zuora Multi-Org enabled, you can use this header to specify which orgs to perform the operation in. If you do not have Zuora Multi-Org enabled, you should not set this header.
The IDs must be a sub-set of the user's accessible orgs. If you specify an org that the user does not have access to, the operation fails. This header is important in Multi-Org (MO) setups because it defines the organization context under which the API should operate—mainly used for read access or data visibility filtering. If the header is not set, the operation is performed in scope of the user's accessible orgs.
Zuora-Versionstring
The minor API version.
For a list of available minor versions, see API upgrades.
This header is returned if you specify the Accept-Encoding: gzip request header and the response contains over 1000 bytes of data.
Note that only the following MIME types support gzipped responses:
application/json
application/xml
text/html
text/csv
text/plain
RateLimit-Limitstring
The request limit quota for the time window closest to exhaustion. See rate limits for more information.
RateLimit-Remainingnumber
The number of requests remaining in the time window closest to quota exhaustion. See rate limits for more information.
RateLimit-Resetnumber
The number of seconds until the quota resets for the time window closest to quota exhaustion. See rate limits for more information.
Zuora-Request-Idstring= 36 characters
The Zuora internal identifier of the API call. You cannot control the value of this header.
Zuora-Track-Idstring<= 64 characters
A custom identifier for tracing the API call. If you specified a tracing identifier in the request headers, Zuora returns the same tracing identifier. Otherwise, Zuora does not set this header.
Concurrency-Limit-Typestring
The type of the concurrency limit, which can be Default, High-volume transactions, or Object Query.
Creates multiple standalone invoices for selling physical goods, services or other items on a non-recurring basis to your subscription customers.
To use this operation, you must have the Modify Invoice and at least one of the Create Standalone Invoice With Product Catalog or Create Standalone Invoice Without Product Catalog user permissions. See Billing Roles for more information.
Limitations
This operation has the following limitations:
You can create a maximum of 50 invoices in one request.
You can create a maximum of 1,000 invoice items in one request.
Security
bearerAuth
Headers
Idempotency-Keystring<= 255 characters
Specify a unique idempotency key if you want to perform an idempotent POST or PATCH request. Do not use this header in other request types.
With this header specified, the Zuora server can identify subsequent retries of the same request using this value, which prevents the same operation from being performed multiple times by accident.
Accept-Encodingstring
Include the Accept-Encoding: gzip header to compress responses as a gzipped file. It can significantly reduce the bandwidth required for a response.
If specified, Zuora automatically compresses responses that contain over 1000 bytes of data, and the response contains a Content-Encoding header with the compression algorithm so that your client can decompress it.
Content-Encodingstring
Include the Content-Encoding: gzip header to compress a request. With this header specified, you should upload a gzipped file for the request payload instead of sending the JSON payload.
Zuora-Track-Idstring<= 64 characters
A custom identifier for tracing the API call. If you set a value for this header, Zuora returns the same value in the response headers. This header enables you to associate your system process identifiers with Zuora API calls, to assist with troubleshooting in the event of an issue.
The value of this field must use the US-ASCII character set and must not include any of the following characters: colon (:), semicolon (;), double quote ("), and quote (').
Zuora-Entity-Idsstring
An entity ID. If you have Zuora Multi-entity enabled and the OAuth token is valid for more than one entity, you must use this header to specify which entity to perform the operation in. If the OAuth token is only valid for a single entity, or you do not have Zuora Multi-entity enabled, you should not set this header.
Zuora-Org-Idsstring
Comma separated IDs. If you have Zuora Multi-Org enabled, you can use this header to specify which orgs to perform the operation in. If you do not have Zuora Multi-Org enabled, you should not set this header.
The IDs must be a sub-set of the user's accessible orgs. If you specify an org that the user does not have access to, the operation fails. This header is important in Multi-Org (MO) setups because it defines the organization context under which the API should operate—mainly used for read access or data visibility filtering. If the header is not set, the operation is performed in scope of the user's accessible orgs.
Zuora-Versionstring
The minor API version.
For a list of available minor versions, see API upgrades.
This header is returned if you specify the Accept-Encoding: gzip request header and the response contains over 1000 bytes of data.
Note that only the following MIME types support gzipped responses:
application/json
application/xml
text/html
text/csv
text/plain
RateLimit-Limitstring
The request limit quota for the time window closest to exhaustion. See rate limits for more information.
RateLimit-Remainingnumber
The number of requests remaining in the time window closest to quota exhaustion. See rate limits for more information.
RateLimit-Resetnumber
The number of seconds until the quota resets for the time window closest to quota exhaustion. See rate limits for more information.
Zuora-Request-Idstring= 36 characters
The Zuora internal identifier of the API call. You cannot control the value of this header.
Zuora-Track-Idstring<= 64 characters
A custom identifier for tracing the API call. If you specified a tracing identifier in the request headers, Zuora returns the same tracing identifier. Otherwise, Zuora does not set this header.
Concurrency-Limit-Typestring
The type of the concurrency limit, which can be Default, High-volume transactions, or Object Query.
Credit memos reduce invoice and account balances. By applying one or more credit memos to invoices with positive balances, you can reduce the invoice balances in the same way that applying a payment to an invoice.
Debit memos increase the amount a customer owes. It is a separate document from the invoice. Debit memos can be used to correct undercharging on an invoice or to levy ad hoc charges outside the context of a subscription. Just like an invoice, debit memo balances can be settled by applying either a payment or a credit memo.
With the E-Invoicing feature, Zuora supports electronic invoices through an integration with partners that have a local presence, where required, which guarantees compliance with local invoice regulations.
All the operations in this section are available only if you have the E-Invoicing feature enabled.
The TaxationItem object is used to add a tax amount to an invoice item. In the typical use case, the tax amount that you specify in the object is calculated by Z-Tax or a third-party tax engine such as Avalara or Connect tax engine.
Changes that you make with this object affect the product charges in your product catalog, but not the charges in existing subscriptions.
You can create billing document sequence sets through the REST API or the Zuora UI, allowing distinct numbering sequences for billing documents, payments, and refunds.
Use operations to generate invoices and credit memos, collect payments for posted invoices, and generate previews of future invoice items for customer accounts.
The Summary Statement feature provides a comprehensive overview of billing activities for each account using HTML templates that compile data like invoices, credit memos, payments, and more. The associated APIs help automate the creation and management of these statements. See Account Summary Statements for more information.
A billing preview run asynchronously generates a downloadable CSV file containing a preview of future invoice item data and credit memo item data for a batch of customer accounts.
Note: Credit memo item data is only available if you have the Invoice Settlement feature enabled.
Open Payment Method (OPM) service is a framework developed by Zuora, which allows you to integrate your custom payment method to Zuora subscription, billing, and revenue management in a dynamic and flexible manner. With the support of the OPM service, you are able to define your custom payment method types and create custom payment methods of the defined types. The custom payment method of the defined type can only be used with the custom payment gateway that you set up through the Universal Payment Connector (UPC) service. It cannot be used with the Zuora out-of-box gateway integrations such as GoCardless, Stripe, etc.
You can define up to 20 custom payment method types for one tenant. Do not define your fields with the Zuora-reserved fields.
Note: You can only use the bearer token to access the "Custom Payment Method Types" API operations. Access with apiAccessKeyId and apiSecretAccessKey is not supported.
Zuora Payment Method Updater (PMU) enables merchants to automatically incorporate changes made to a customer's credit cards. For more information about Zuora PMU, see Payment Method Updater.
A Payment Method Snapshot is a copy of the particular Payment Method used in a transaction. If the Payment Method is deleted, the Snapshot continues to retain the data used in each of the past transactions. As such, the Snapshot helps with display of historical transactions, integrations to external systems, and reporting.
Hosted payment pages allow your customers to set up a payment method, such as providing a credit card. Since it only handles the payment method, it is suitable for a simple workflow or a complex multi-page, multi-product workflow.
The REST API used in Payment Pages 2.0 are CORS (Cross-Origin Resource Sharing) enabled and therefore requires a digital signature.
You can use the Generate an RSA signature operation to generate the required digital signature and token for a Payment Pages 2.0 form, then use the Decrypt an RSA signature operation to decrypt the signature to validate the signature and key."
Gateway reconciliation is the process of verifying that the electronic payment and refund transactions processed in Zuora match the transactions reported by the gateway. For example, if Zuora processed 200 transactions through a gateway, you should see the same number of transactions on the gateway's reconciliation report, sometimes also called the settlement report.
You can complete the following Gateway Reconciliation tasks through API:
Use payments to process payments, for example, automate recurring payments, manage overpayments, and create refunds. For more information about payments, see Payments.
Use payment runs to collect payments using electronic payment methods, for example, credit cards and ACH. For more information about payment runs, see Payment Runs.
Use payment schedules to split invoice or account balances into several installments and automatically process payments for the installments. For more information about payment schedules, see Payment Schedules.
Zuora allows you to issue and track refunds on payments. Similar to external payments, users can enter external refunds to track refunds that have been performed outside of Zuora Payments (for example, by issuing a check). In addition, you can make electronic refunds using our supported payment gateways, which will automatically refund money to the customer.
Configurable Payment Retry APIs use basic authentication. The user name is the email address that you use for logging in Zuora. The password is the API token that is shown in the settings of Configurable Payment Retry. Click the drop-down arrow at the end of an endpoint to display the full endpoint. To learn more about the configuration and usage of Configurable Payment Retry, see Configurable Payment Retry.
The Object Query API contains GET operations that allow you to query objects in your Zuora tenant in an efficient, consistent, and flexible manner.
With the expand[] and filter[] query parameters, you have the flexibility to retrieve related object information in a single call and define the returned response that best suits your needs. You can also use the fields[] query parameter to define which fields are returned in the response for a given object. The sort[] query parameter allows you to sort the results in ascending or descending order based on the specified field.
These parameters are case-insensitive matching.
For general Object Queries limitations and comprehensive introduction to these query parameters, see Expand, filter, fields, and sort.
For filterable, expandable, and sortable fields on each object, refer to the Query Parameters section for each API operation.
Accounting Codes are commonly referred to as General Ledger Accounts or General Ledger Account Codes. In Zuora, the use of accounting codes are optional but recommended.
This section contains the operations that allow you to create, update, get, delete, activate, or deactivate accounting codes in Zuora.
A key step in configuring Finance is to create accounting periods in Zuora to match your company's financial calendar. This allows Zuora to produce reports and data exports organized by accounting periods, and to perform the work of closing the accounting periods for the revenue sub-ledger.
A summary journal entry is a summary of Zuora transaction amounts organized by accounting code and general ledger segments. A segment adds more reporting granularity through business dimensions, such as country or product.
Notifications are the actions taken to inform users or call third-party endpoints when a certain event happens. Typical actions include emails and callouts. Callouts typically refer to HTTP invocations, such as HTTP calls to REST services.
Zuora notification system processes the events in the same order in which they are triggered. The timing and delivery of notifications can still vary based on factors such as retries, concurrency, and network latency. But Zuora guarantees the best performance possible with the right performance boosters and tuning.
Notifications are associated with Communication Profiles, which allow you to send specific event-driven notifications to targeted customers. Zuora provides the following Settings API to access the settings of Communication Profiles:* Get all Communication Profiles
The Event Trigger service manages the business events and trigger conditions that are defined on Zuora Business Object Model or custom objects. When a Zuora object changes, the trigger conditions defined on the object are evaluated, and if any condition qualifies, a business event will be triggered and turned into a notification.
Note: Event Triggers operations are only applicable to custom events.
A custom scheduled event notification is evaluated at the scheduled time of the related scheduled event on a daily basis. If the date meets the combination of the base field and the notification parameters, the notification will be triggered immediately.
With Custom Objects service, you can define custom objects, extending the Zuora data model to accommodate your specific use cases.
If you use Postman, you can import the custom objects endpoints as a collection into your Postman app and try out different requests to learn how the API works.
You can sign up for a free account on the Postman website and download the app in case you do not use Postman yet.
Note that the Custom Object Definitions API is versioned by Zuora-Version in the request header. The response may be different for the same request with a different API version. Specify Zuora-Version in the request header if you expect a specific response schema.
With Custom Objects service, you can create, update, delete and find custom object records.
If you use Postman, you can import the custom objects endpoints as a collection into your Postman app and try out different requests to learn how the API works.
You can sign up for a free account on the Postman website and download the app in case you do not use Postman yet.
Note that the Custom Object Records API is versioned by Zuora-Version in the request header. The response may be different for the same request with a different API version. Specify Zuora-Version in the request header if you expect a specific response schema.
With Custom Objects service, you can submit a bulk job request to create, update, or delete custom object records in a batch.
If you use Postman, you can import the custom objects endpoints as a collection into your Postman app and try out different requests to learn how the API works.
You can sign up for a free account on the Postman website and download the app in case you do not use Postman yet.
Note that the Custom Object Jobs API is versioned by Zuora-Version in the request header. The response may be different for the same request with a different API version. Specify Zuora-Version in the request header if you expect a specific response schema.
Zuora System Health dashboard for API (API dashboard) collects and displays data about API usage, failure, performance, and concurrency limit in near real time. It enables you to view all the APIs in your Zuora tenant within the last 14 days. For more information, see APIs dashboard.
Zuora System Health dashboard for Bill Run (Bill Run dashboard) collects and displays data about bill run usage, failure, and performance in near real time. Through the Bill Run dashboard, you can view data about all the bill runs in your Zuora tenant within the last 30 days. For more information, see Bill Run dashboard.
Zuora System Health dashboard for Electronic Payments (Electronic Payment dashboard) collects and displays usage, failure, and performance data about electronic payments in near real time. It enables you to view all the electronic payments in your Zuora tenant within the last 30 days. For more information, see Electronic Payments dashboard.
Zuora System Health dashboard for Tax Health (Tax Health dashboard) collects and displays usage, failure, and performance data about Tax in near real time. It enables you to view all the tax details in your Zuora tenant within the last 30 days. For more information, see Tax Health Dashboard.
A workflow is a sequence of tasks that are performed based on predefined logic. A workflow improves efficiency and reduces errors by automating a series of complex tasks that otherwise need to be performed manually and repetitively.
The Data Query feature enables you to perform SQL queries in your Zuora tenant. To learn how to get started with Data Query, see Overview of Data Query.
The Aggregate Query API (AQuA) is a REST API that executes multiple Export ZOQL or ZOQL queries. The queries are performed in a sequential order and in a single read-only database transaction.
AQuA enforces the following limits:
The maximum processing time per query is 3 hours. If a query in an AQuA job is executed for longer than 3 hours, this job will be killed automatically. See the best practices for bulk data extraction with AQuA.
AQuA enforces limits on both the stateful concurrent AQuA jobs and the stateless concurrent AQuA jobs per tenant:
The maximum number of stateful concurrent AQuA jobs per tenant is 50. - The maximum number of stateless concurrent AQuA jobs per tenant is 50. AQuA jobs in the following status are counted towards your concurrent AQuA job limits:
Submitted - Executing Zuora system will reject the subsequent stateful or stateless job requests once the corresponding concurrent job limit is reached.
For more information about the Aggregate Query API(AQuA), see Aggregate Query.
Configuration Templates in Zuora Deployment Manager enable you to configure your tenants in minutes by importing a templated metadata configuration file. This feature eliminates the need for long manual configuration processes that would have previously taken hours. You will be able to access a comprehensive repository of industry-specific templates. It will be easier for you to deploy and release. To use this API for migrating metadata from a source tenant to a destination tenant, you should authenticate using credentials of the source tenant The user will have to provide the client id and secret key from the sou.rce tenant. To understand the known behavior of configuration templates and APIs, see the following sections: Product Catalog deployment known facts and system behaviorProduct Catalog deployment FAQsDeployment Manager Known Facts and Limitations
The Metadata API in Zuora promotes a programmatic way to retrieve, compare, and validate metadata within Zuora tenants for performing create and update actions between the source and the target. To use this API for migrating metadata from a source tenant to a destination tenant, you should authenticate using credentials of the source tenant. The user will have to provide the client id and secret key from the source tenant. To understand the known behavior of configuration templates and APIs, see the following sections: Product Catalog deployment known facts and system behaviorProduct Catalog deployment FAQsDeployment Manager Known Facts and Limitations
The Bulk Data API operations allow you to manage bulk data loader services and perform programmatic CRUD (Create, Update, Read/export, Delete) operations. To perform data ingestion with a CSV file in Zuora Billing using the Data Loader Bulk Data APIs, see Tutorial for Bulk job API with CSV. For more information, see Process Bulk Job with JSON-lines in Data Loader.
System for Cross-domain Identity Management, or SCIM, is an API specification created to facilitate the management of people and groups of people in cloud-based applications and services. Universal Identity SCIM API is built on top of the SCIM 2.0 specification and can be integrated with major Identity Providers like Okta, Microsoft Entra ID and OneLogin.
Zuora recommends that you use OAuth v2.0 to authenticate to the Zuora REST API.
You must first create an OAuth client in the Zuora UI before using the Create an OAuth token operation to create an OAuth token. See Authentication for more information.
The Data Labeling APIs help you to label your existing data with organization(s) in Zuora.
Once you turned on Multi Org feature, if you don't label your existing data, they are simply unlabeled, and unlabeled data can be accessed by all organizations in your tenant.
To limit the access of your existing data, you need to label them with organization(s) you defined in the organization hierarchy management setting page. Once labeled, the data can only be accessed by users who have been granted with the labeled organization(s).
Note that you have to enable the "Multi Org" feature before using the Data Labeling APIs.
A Test Environment is a dedicated sandbox tenant designed for development, integration, and user acceptance testing of your system configurations and business processes.
A Test Environment Job represents an asynchronous operation initiated to refresh a Test Environment. These jobs track the status and progress of environment provisioning and refresh.
Actions are operations that are batch in nature. For example, the "create", "update", "delete", and other operations allow changes to up-to 50 objects at a time. The "query" operation will return up-to 2000 result records back at a time, before requiring additional pages of data to be returned via a subsequent "queryMore" operation.
The default WSDL version for Actions is 79. If you want to change the WSDL version, set the X-Zuora-WSDL-Version header. To find out in which WSDL version a particular object or field was introduced, see Zuora SOAP API Version History.
Note: Actions do not support the Invoice Settlement feature. This feature includes Unapplied Payments, Credit and Debit Memo, and Invoice Item Settlement. Actions also do not support the Orders feature.
The Setting API provides a central API for managing settings in your Zuora tenant.
If you use Postman, you can import the Settings API endpoints as a collection into your Postman app and try out different requests to learn how the API works. You can sign up for a free account on the Postman website and download the app in case you do not use Postman yet.
An import uploads content, especially when you have a large amount of content. The Import object contains all of the information you need to upload content, such as a large number of usage records.
If you use a custom exchange rate provider and upload rates with the Import Foreign Exchange Rates mass action, you can query custom foreign exchange rates from Zuora through API.
This feature is in Limited Availability. If you wish to have access to the feature, submit a request at Zuora Global Support.
Use attachments in Zuora to upload documents of various formats to associate additional information with accounts, subscriptions, invoices, credit memos, or debit memos. Example attachments could be purchase orders (PO's), tax exemption document, or ownership transfer forms.
For more information about attachments, see Attachments.
Note - The APIs in this section are legacy APIs. Zuora recommends using the newer, faster APIs for managing products and catalogs more efficiently instead. For more information, see our latest Commerce API.
A product is an item or service that your company sells. In the subscription economy, a product is generally a service that your customers subscribe to rather than a physical item that they purchase one time. For example, customers subscribe to a service that provides them a car when and where they need a car rather than buying a car outright.
A Product object contains all of the items in a specific product, especially product rate plans and product rate plan charges. Each Product object can have multiple rate plans, which in turn can each have multiple rate plan charges. Each rate plan charge can have multiple tiers. Taken together, all of these items create a single product.
Customers subscribe to products that are in your product catalog. Product objects collectively compose your product catalog. You create your product catalog by creating products. As soon as you create your first product, you create your product catalog.
Note - The APIs in this section are legacy APIs. Zuora recommends using the newer, faster APIs for managing products and catalogs more efficiently instead. For more information, see our latest Commerce API.
The Zuora Billing product catalog is where you define your products and pricing. The product catalog's ability to handle sophisticated pricing models gives you the power to easily adapt your pricing to customer and market needs, to grow your business and drive more revenue.
Note - The APIs in this section are legacy APIs. Zuora recommends using the newer, faster APIs for managing products and catalogs more efficiently instead. For more information, see our latest Commerce API.
A catalog group is used to group a list of product rate plans with a specific grade.
Note - The APIs in this section are legacy APIs. Zuora recommends using the newer, faster APIs for managing products and catalogs more efficiently instead. For more information, see our latest Commerce API.
A product rate plan is the part of a product that your customers subscribe to. Each product can have multiple product rate plans, and each product rate plan can have multiple product rate plan charges, which are fees for products and their product rate plans.
Note - The APIs in this section are legacy APIs. Zuora recommends using the newer, faster APIs for managing products and catalogs more efficiently instead. For more information, see our latest Commerce API.
Use product rate plan definitions to reuse charges in different product rate plans. The Product Rate Plan Definition object is in the Early Adopter phase. We are actively soliciting feedback from a small set of early adopters before releasing it as generally available. If you are interested, please reach out to your CSM.
Note - The APIs in this section are legacy APIs. Zuora recommends using the newer, faster APIs for managing products and catalogs more efficiently instead. For more information, see our latest Commerce API.
A product rate plan charge represents a charge model or a set of fees associated with a product rate plan, which is the part of a product that your customers subscribe to. Each product rate plan can have multiple product rate plan charges.
Product rate plan charges can be of three types: one-time fees, recurring fees, and usage fees. For example, the $50 activation fee for the Topaz product rate plan is a one-time product rate plan charge.
Note - The APIs in this section are legacy APIs. Zuora recommends using the newer, faster APIs for managing products and catalogs more efficiently instead. For more information, see our latest Commerce API.
Use product charge definitions to define the attributes that can determine the charge behavior, such as billing attributes, pricing attributes, taxation attributes, or accounting attributes.\n\nThe Product Charge Definition object is in the Early Adopter phase. We are actively soliciting feedback from a small set of early adopters before releasing it as generally available. If you are interested, please reach out to your CSM.
Note - The APIs in this section are legacy APIs. Zuora recommends using the newer, faster APIs for managing products and catalogs more efficiently instead. For more information, see our latest Commerce API.
To manage product rate plan charge tiers, use the Product Rate Plan Charges operations instead to update the corresponding product rate plan charge with all the tiers.
Note: You can only use the operations in this section if you have the Billing - Revenue Integration feature enabled. See Billing - Revenue Integration for more information. The APIs in this section are legacy APIs. Zuora recommends using the newer, faster APIs for managing products and catalogs more efficiently instead. For more information, see our latest Commerce API.