Mock sample for your project: The Plaid API
Integrate with "The Plaid API" from plaid.com in no time with Mockoon's ready to use mock sample
The Plaid API
Version: 2020-09-14_1.20.6
Start working with "The Plaid API" right away by using this ready-to-use mock sample. API mocking can greatly speed up your application development by removing all the tedious tasks or issues: API key provisioning, account creation, unplanned downtime, etc.
It also helps reduce your dependency on third-party APIs and improves your integration tests' quality and reliability by accounting for random failures, slow response time, etc.
Description
The Plaid REST API. Please see https://plaid.com/docs/api for more details.
Other APIs in the same category
Business Registries
ato.gov.au
Introduction
The Business Registries API is built on HTTP. The API is RESTful. It has predictable resource URIs.
The API is documented in OpenAPI format.
In addition to the standard OpenAPI syntax we use a few
vendor extensions.
Overview
The following sections describe the resources that make up the Business Registries REST API.
Current Version
By default, all requests to https://api.abr.ato.gov.au receive the v1 version of the REST API. We encourage you to explicitly request this version via the Accept header.
Accept: application/vnd.abr-ato.v1+json
Schema
All API access is over HTTPS, and accessed from https://api.abr.ato.gov.au. All data is sent and received as JSON. Blank fields are included.
All dates use the ISO 8601 format:
YYYY-MM-DD
For example: 2017-07-01 (the 1st of July 2017)
All timestamps use the ISO 8601 format:
YYYY-MM-DDTHH:MM:SSZ
For example: 2017-07-01T11:05:06+10:00
Timezones
Some requests allow for specifying timestamps or generate timestamps with time zone information. We apply the following rules, in order of priority, to determine timezone information for API calls.
Explicitly provide an ISO 8601 timestamp with timezone information
For API calls that allow for a timestamp to be specified, we use that exact timestamp.
For example: 2017-07-01T11:05:06+10:00
Pagination
Information about pagination is provided in the Link header.
For example:
Link:; rel="next",; rel="last"
rel="next" states that the next page is page=2. This makes sense, since by default, all paginated queries start at page 1. rel="last" provides some more information, stating that the last page of results is on page 34. Accordingly, we have 33 more pages of information that we can consume.
Parameters
Many API methods take optional parameters:
GET /individuals/1234/addresses/?addressType='Mailing'
In this example, the '1234' value is provided for the :partyId parameter in the path while :addressType is passed in the query string.
For POST, PATCH, PUT, and DELETE requests, parameters not included in the URL should be encoded as JSON with a Content-Type of 'application/json'.
Metadata
The API provides metadata services that you can use to discover information about the classifcation schemes and values used by the Registry.
For example:
GET /classifications/roles
Sample response:
[
{
"id": "123e4567-e89b-12d3-a456-426655440001",
"role": "Director",
"roleDescription": "An individual responsible for managing a company's ...",
"relationship": "Directorship",
"reciprocalRole": "Company",
"reciprocalRoleDescription": "An incorporated legal entity."
},
{
...
}
]
Root Endpoint
You can issue a GET request to the root endpoint (also known as the service root) to get all the endpoint categories that the REST API supports:
curl https://api.abr.ato.gov.au
Authentication
The Business Registries API supports API Key authentication.
When you sign up for an account, you are given your first API key. You can generate additional API keys, and delete
API keys (as you may need to rotate your keys in the future). You authenticate to the Business Registries API by
providing your secret key in the request header.
Note: Some requests will return 404 Not Found, instead of 403 Permission Denied. This is to prevent the
accidental leakage of information to unauthorised users.
The Business Registries API is built on HTTP. The API is RESTful. It has predictable resource URIs.
The API is documented in OpenAPI format.
In addition to the standard OpenAPI syntax we use a few
vendor extensions.
Overview
The following sections describe the resources that make up the Business Registries REST API.
Current Version
By default, all requests to https://api.abr.ato.gov.au receive the v1 version of the REST API. We encourage you to explicitly request this version via the Accept header.
Accept: application/vnd.abr-ato.v1+json
Schema
All API access is over HTTPS, and accessed from https://api.abr.ato.gov.au. All data is sent and received as JSON. Blank fields are included.
All dates use the ISO 8601 format:
YYYY-MM-DD
For example: 2017-07-01 (the 1st of July 2017)
All timestamps use the ISO 8601 format:
YYYY-MM-DDTHH:MM:SSZ
For example: 2017-07-01T11:05:06+10:00
Timezones
Some requests allow for specifying timestamps or generate timestamps with time zone information. We apply the following rules, in order of priority, to determine timezone information for API calls.
Explicitly provide an ISO 8601 timestamp with timezone information
For API calls that allow for a timestamp to be specified, we use that exact timestamp.
For example: 2017-07-01T11:05:06+10:00
Pagination
Information about pagination is provided in the Link header.
For example:
Link:; rel="next",; rel="last"
rel="next" states that the next page is page=2. This makes sense, since by default, all paginated queries start at page 1. rel="last" provides some more information, stating that the last page of results is on page 34. Accordingly, we have 33 more pages of information that we can consume.
Parameters
Many API methods take optional parameters:
GET /individuals/1234/addresses/?addressType='Mailing'
In this example, the '1234' value is provided for the :partyId parameter in the path while :addressType is passed in the query string.
For POST, PATCH, PUT, and DELETE requests, parameters not included in the URL should be encoded as JSON with a Content-Type of 'application/json'.
Metadata
The API provides metadata services that you can use to discover information about the classifcation schemes and values used by the Registry.
For example:
GET /classifications/roles
Sample response:
[
{
"id": "123e4567-e89b-12d3-a456-426655440001",
"role": "Director",
"roleDescription": "An individual responsible for managing a company's ...",
"relationship": "Directorship",
"reciprocalRole": "Company",
"reciprocalRoleDescription": "An incorporated legal entity."
},
{
...
}
]
Root Endpoint
You can issue a GET request to the root endpoint (also known as the service root) to get all the endpoint categories that the REST API supports:
curl https://api.abr.ato.gov.au
Authentication
The Business Registries API supports API Key authentication.
When you sign up for an account, you are given your first API key. You can generate additional API keys, and delete
API keys (as you may need to rotate your keys in the future). You authenticate to the Business Registries API by
providing your secret key in the request header.
Note: Some requests will return 404 Not Found, instead of 403 Permission Denied. This is to prevent the
accidental leakage of information to unauthorised users.
Ntropy Transaction API
ntropy.network
Ntropy Transaction API for transaction classification & management
Contact Support:
Name: API Support
Email: [email protected]
Contact Support:
Name: API Support
Email: [email protected]
nFusion Solutions Market Data API v1
nFusion Solutions provides REST APIs that deliver enterprise-grade financial data. Data sets include real-time and historical pricing for Spot prices of precious metals such as Gold, Silver, Platinum, and Palladium, exchange rates for major currency pairs, exchange rates for Crypto Currencies such as BTC, ETH, and LTC. All API access requires authentication. In order to be issued access credentials you must first enter into a service agreement with nFusion Solutions and acquire a commercial license. For information on how to obtain a licence take a tour of our products or email [email protected].
API Reference: Billing
zuora.com
Introduction
Welcome to the reference for the Zuora Billing REST API!
To learn about the common use cases of Zuora Billing REST APIs, check out the API Guides.
In addition to Zuora API Reference; Billing, we also provide API references for other Zuora products:
API Reference: Collect
API Reference: Revenue
The Zuora REST API provides a broad set of operations and resources that:
Enable Web Storefront integration from your website.
Support self-service subscriber sign-ups and account management.
Process revenue schedules through custom revenue rule models.
Enable manipulation of most objects in the Zuora Billing Object Model.
Want to share your opinion on how our API works for you? Tell us how you feel about using our API and what we can do to make it better.
Access to the API
If you have a Zuora tenant, you can access the Zuora REST API via one of the following endpoints:
| Tenant | Base URL for REST Endpoints |
|-------------------------|-------------------------|
|US Production | https://rest.zuora.com |
|US API Sandbox | https://rest.apisandbox.zuora.com|
|US Performance Test | https://rest.pt1.zuora.com |
|US Production Copy | Submit a request at Zuora Global Support to enable the Zuora REST API in your tenant and obtain the base URL for REST endpoints. See REST endpoint base URL of Production Copy (Service) Environment for existing and new customers for more information. |
|US Cloud Production | https://rest.na.zuora.com |
|US Cloud API Sandbox | https://rest.sandbox.na.zuora.com |
|US Central Sandbox | https://rest.test.zuora.com |
|EU Production | https://rest.eu.zuora.com |
|EU API Sandbox | https://rest.sandbox.eu.zuora.com |
|EU Central Sandbox | https://rest.test.eu.zuora.com |
The Production endpoint provides access to your live user data. Sandbox tenants are a good place to test code without affecting real-world data. If you would like Zuora to provision a Sandbox tenant for you, contact your Zuora representative for assistance.
If you do not have a Zuora tenant, go to https://www.zuora.com/resource/zuora-test-drive and sign up for a Production Test Drive tenant. The tenant comes with seed data, including a sample product catalog.
API Changelog
You can find the Changelog of the API Reference: Billing in the Zuora Community.
Authentication
OAuth v2.0
Zuora recommends that you use OAuth v2.0 to authenticate to the Zuora REST API. Currently, OAuth is not available in every environment. See Zuora Testing Environments for more information.
Zuora recommends you to create a dedicated API user with API write access on a tenant when authenticating via OAuth, and then create an OAuth client for this user. See Create an API User for how to do this. By creating a dedicated API user, you can control permissions of the API user without affecting other non-API users.
If a user is deactivated, all of the user's OAuth clients will be automatically deactivated.
Authenticating via OAuth requires the following steps:
Create a Client
Generate a Token
Make Authenticated Requests
Create a Client
You must first create an OAuth client in the Zuora UI. To do this, you must be an administrator of your Zuora tenant. This is a one-time operation. You will be provided with a Client ID and a Client Secret. Please note this information down, as it will be required for the next step.
Note: The OAuth client will be owned by a Zuora user account. If you want to perform PUT, POST, or DELETE operations using the OAuth client, the owner of the OAuth client must have a Platform role that includes the "API Write Access" permission.
Generate a Token
After creating a client, you must make a call to obtain a bearer token using the Generate an OAuth token operation. This operation requires the following parameters:
client_id - the Client ID displayed when you created the OAuth client in the previous step
client_secret - the Client Secret displayed when you created the OAuth client in the previous step
granttype - must be set to clientcredentials
Note: The Client ID and Client Secret mentioned above were displayed when you created the OAuth Client in the prior step. The Generate an OAuth token response specifies how long the bearer token is valid for. You should reuse the bearer token until it is expired. When the token is expired, call Generate an OAuth token again to generate a new one.
Make Authenticated Requests
To authenticate subsequent API requests, you must provide a valid bearer token in an HTTP header:
Authorization: Bearer {bearer_token}
If you have Zuora Multi-entity enabled, you need to set an additional header to specify the ID of the entity that you want to access. You can use the scope field in the Generate an OAuth token response to determine whether you need to specify an entity ID.
If the scope field contains more than one entity ID, you must specify the ID of the entity that you want to access. For example, if the scope field contains entity.1a2b7a37-3e7d-4cb3-b0e2-883de9e766cc and entity.c92ed977-510c-4c48-9b51-8d5e848671e9, specify one of the following headers:
Zuora-Entity-Ids: 1a2b7a37-3e7d-4cb3-b0e2-883de9e766cc
Zuora-Entity-Ids: c92ed977-510c-4c48-9b51-8d5e848671e9
Note: For a limited period of time, Zuora will accept the entityId header as an alternative to the Zuora-Entity-Ids header. If you choose to set the entityId header, you must remove all "-" characters from the entity ID in the scope field.
If the scope field contains a single entity ID, you do not need to specify an entity ID.
Other Supported Authentication Schemes
Zuora continues to support the following additional legacy means of authentication:
Use username and password. Include authentication with each request in the header:
apiAccessKeyId
apiSecretAccessKey
Zuora recommends that you create an API user specifically for making API calls. See Create an API User for more information.
Use an authorization cookie. The cookie authorizes the user to make calls to the REST API for the duration specified in Administration > Security Policies > Session timeout. The cookie expiration time is reset with this duration after every call to the REST API. To obtain a cookie, call the Connections resource with the following API user information:
ID
Password
For CORS-enabled APIs only: Include a 'single-use' token in the request header, which re-authenticates the user with each request. See below for more details.
Entity Id and Entity Name
The entityId and entityName parameters are only used for Zuora Multi-entity. These are the legacy parameters that Zuora will only continue to support for a period of time. Zuora recommends you to use the Zuora-Entity-Ids parameter instead.
The entityId and entityName parameters specify the Id and the name of the entity that you want to access, respectively. Note that you must have permission to access the entity.
You can specify either the entityId or entityName parameter in the authentication to access and view an entity.
If both entityId and entityName are specified in the authentication, an error occurs.
If neither entityId nor entityName is specified in the authentication, you will log in to the entity in which your user account is created.
To get the entity Id and entity name, you can use the GET Entities REST call. For more information, see API User Authentication.
Token Authentication for CORS-Enabled APIs
The CORS mechanism enables REST API calls to Zuora to be made directly from your customer's browser, with all credit card and security information transmitted directly to Zuora. This minimizes your PCI compliance burden, allows you to implement advanced validation on your payment forms, and makes your payment forms look just like any other part of your website.
For security reasons, instead of using cookies, an API request via CORS uses tokens for authentication.
The token method of authentication is only designed for use with requests that must originate from your customer's browser; it should not be considered a replacement to the existing cookie authentication mechanism.
See Zuora CORS REST for details on how CORS works and how you can begin to implement customer calls to the Zuora REST APIs. See HMAC Signatures for details on the HMAC method that returns the authentication token.
Requests and Responses
Request IDs
As a general rule, when asked to supply a "key" for an account or subscription (accountKey, account-key, subscriptionKey, subscription-key), you can provide either the actual ID or the number of the entity.
HTTP Request Body
Most of the parameters and data accompanying your requests will be contained in the body of the HTTP request.
The Zuora REST API accepts JSON in the HTTP request body. No other data format (e.g., XML) is supported.
Data Type
(Actions and CRUD operations only) We recommend that you do not specify the decimal values with quotation marks, commas, and spaces. Use characters of +-0-9.eE, for example, 5, 1.9, -8.469, and 7.7e2. Also, Zuora does not convert currencies for decimal values.
Testing a Request
Use a third party client, such as curl, Postman, or Advanced REST Client, to test the Zuora REST API.
You can test the Zuora REST API from the Zuora API Sandbox or Production tenants. If connecting to Production, bear in mind that you are working with your live production data, not sample data or test data.
Testing with Credit Cards
Sooner or later it will probably be necessary to test some transactions that involve credit cards. For suggestions on how to handle this, see [Going Live With Your Payment Gateway](https://knowledgecenter.zuora.com/CBBilling/MPaymentGateways/CManagingPaymentGateways/BGoingLivePaymentGateways#TestingwithCreditCards "CZuoraUserGuides/ABillingandPayments/MPaymentGateways/CManagingPaymentGateways/BGoingLivePaymentGateways#TestingwithCredit_Cards"
).
Concurrent Request Limits
Zuora enforces tenant-level concurrent request limits. See Concurrent Request Limits for more information.
Timeout Limit
If a request does not complete within 120 seconds, the request times out and Zuora returns a Gateway Timeout error.
Error Handling
If a request to Zuora Billing REST API with an endpoint starting with /v1 (except Actions and CRUD operations) fails, the response will contain an eight-digit error code with a corresponding error message to indicate the details of the error.
The following code snippet is a sample error response that contains an error code and message pair:
The success field indicates whether the API request has succeeded. The processId field is a Zuora internal ID that you can provide to Zuora Global Support for troubleshooting purposes.
The reasons field contains the actual error code and message pair. The error code begins with 5 or 6 means that you encountered a certain issue that is specific to a REST API resource in Zuora Billing. For example, 53100320 indicates that an invalid value is specified for the termType field of the subscription object.
The error code beginning with 9 usually indicates that an authentication-related issue occurred, and it can also indicate other unexpected errors depending on different cases. For example, 90000011 indicates that an invalid credential is provided in the request header.
When troubleshooting the error, you can divide the error code into two components: REST API resource code and error category code. See the following Zuora error code sample:
Note: Zuora determines resource codes based on the request payload. Therefore, if GET and DELETE requests that do not contain payloads fail, you will get 500000 as the resource code, which indicates an unknown object and an unknown field.
The error category code of these requests is valid and follows the rules described in the Error Category Code section.
In such case, you can refer to the returned error message to troubleshoot.
REST API Resource Code
The 6-digit resource code indicates the REST API resource, typically a field of a Zuora object, on which the issue occurs. In the preceding example, 531003 refers to the termType field of the subscription object.
The value range for all REST API resource codes is from 500000 to 679999. See Resource Codes in the Knowledge Center for a full list of resource codes.
Error Category Code
The 2-digit error category code identifies the type of error, for example, resource not found or missing required field.
The following table describes all error categories and the corresponding resolution:
| Code | Error category | Description | Resolution |
|:--------|:--------|:--------|:--------|
| 10 | Permission or access denied | The request cannot be processed because a certain tenant or user permission is missing. | Check the missing tenant or user permission in the response message and contact Zuora Global Support for enablement. |
| 11 | Authentication failed | Authentication fails due to invalid API authentication credentials. | Ensure that a valid API credential is specified. |
| 20 | Invalid format or value | The request cannot be processed due to an invalid field format or value. | Check the invalid field in the error message, and ensure that the format and value of all fields you passed in are valid. |
| 21 | Unknown field in request | The request cannot be processed because an unknown field exists in the request body. | Check the unknown field name in the response message, and ensure that you do not include any unknown field in the request body. |
| 22 | Missing required field | The request cannot be processed because a required field in the request body is missing. | Check the missing field name in the response message, and ensure that you include all required fields in the request body. |
| 30 | Rule restriction | The request cannot be processed due to the violation of a Zuora business rule. | Check the response message and ensure that the API request meets the specified business rules. |
| 40 | Not found | The specified resource cannot be found. | Check the response message and ensure that the specified resource exists in your Zuora tenant. |
| 45 | Unsupported request | The requested endpoint does not support the specified HTTP method. | Check your request and ensure that the endpoint and method matches. |
| 50 | Locking contention | This request cannot be processed because the objects this request is trying to modify are being modified by another API request, UI operation, or batch job process. | Resubmit the request first to have another try. If this error still occurs, contact Zuora Global Support with the returned Zuora-Request-Id value in the response header for assistance. |
| 60 | Internal error | The server encounters an internal error. | Contact Zuora Global Support with the returned Zuora-Request-Id value in the response header for assistance. |
| 70 | Request exceeded limit | The total number of concurrent requests exceeds the limit allowed by the system. | Resubmit the request after the number of seconds specified by the Retry-After value in the response header. Check Concurrent request limits for details about Zuora’s concurrent request limit policy. |
| 90 | Malformed request | The request cannot be processed due to JSON syntax errors. | Check the syntax error in the JSON request body and ensure that the request is in the correct JSON format. |
| 99 | Integration error | The server encounters an error when communicating with an external system, for example, payment gateway, tax engine provider. | Check the response message and take action accordingly. |
Pagination
When retrieving information (using GET methods), the optional pageSize query parameter sets the maximum number of rows to return in a response. The maximum is 40; larger values are treated as 40. If this value is empty or invalid, pageSize typically defaults to 10.
The default value for the maximum number of rows retrieved can be overridden at the method level.
If more rows are available, the response will include a nextPage element, which contains a URL for requesting the next page. If this value is not provided, no more rows are available. No "previous page" element is explicitly provided; to support backward paging, use the previous call.
Array Size
For data items that are not paginated, the REST API supports arrays of up to 300 rows. Thus, for instance, repeated pagination can retrieve thousands of customer accounts, but within any account an array of no more than 300 rate plans is returned.
API Versions
The Zuora REST API are version controlled. Versioning ensures that Zuora REST API changes are backward compatible. Zuora uses a major and minor version nomenclature to manage changes. By specifying a version in a REST request, you can get expected responses regardless of future changes to the API.
Major Version
The major version number of the REST API appears in the REST URL. Currently, Zuora only supports the v1 major version. For example, POST https://rest.zuora.com/v1/subscriptions.
Minor Version
Zuora uses minor versions for the REST API to control small changes. For example, a field in a REST method is deprecated and a new field is used to replace it.
Some fields in the REST methods are supported as of minor versions. If a field is not noted with a minor version, this field is available for all minor versions. If a field is noted with a minor version, this field is in version control. You must specify the supported minor version in the request header to process without an error.
If a field is in version control, it is either with a minimum minor version or a maximum minor version, or both of them. You can only use this field with the minor version between the minimum and the maximum minor versions. For example, the invoiceCollect field in the POST Subscription method is in version control and its maximum minor version is 189.0. You can only use this field with the minor version 189.0 or earlier.
If you specify a version number in the request header that is not supported, Zuora will use the minimum minor version of the REST API. In our REST API documentation, if a field or feature requires a minor version number, we note that in the field description.
You only need to specify the version number when you use the fields require a minor version. To specify the minor version, set the zuora-version parameter to the minor version number in the request header for the request call. For example, the collect field is in 196.0 minor version. If you want to use this field for the POST Subscription method, set the zuora-version parameter to 196.0 in the request header. The zuora-version parameter is case sensitive.
For all the REST API fields, by default, if the minor version is not specified in the request header, Zuora will use the minimum minor version of the REST API to avoid breaking your integration.
Minor Version History
The supported minor versions are not serial. This section documents the changes made to each Zuora REST API minor version.
The following table lists the supported versions and the fields that have a Zuora REST API minor version.
| Fields | Minor Version | REST Methods | Description |
|:--------|:--------|:--------|:--------|
| invoiceCollect | 189.0 and earlier | Create Subscription; Update Subscription; Renew Subscription; Cancel Subscription; Suspend Subscription; Resume Subscription; Create Account|Generates an invoice and collects a payment for a subscription. |
| collect | 196.0 and later | Create Subscription; Update Subscription; Renew Subscription; Cancel Subscription; Suspend Subscription; Resume Subscription; Create Account|Collects an automatic payment for a subscription. |
| invoice | 196.0 and 207.0| Create Subscription; Update Subscription; Renew Subscription; Cancel Subscription; Suspend Subscription; Resume Subscription; Create Account|Generates an invoice for a subscription. |
| invoiceTargetDate | 196.0 and earlier | Preview Subscription |Date through which charges are calculated on the invoice, as yyyy-mm-dd. |
| invoiceTargetDate | 207.0 and earlier | Create Subscription; Update Subscription; Renew Subscription; Cancel Subscription; Suspend Subscription; Resume Subscription; Create Account|Date through which charges are calculated on the invoice, as yyyy-mm-dd. |
| targetDate | 207.0 and later | Preview Subscription |Date through which charges are calculated on the invoice, as yyyy-mm-dd. |
| targetDate | 211.0 and later | Create Subscription; Update Subscription; Renew Subscription; Cancel Subscription; Suspend Subscription; Resume Subscription; Create Account|Date through which charges are calculated on the invoice, as yyyy-mm-dd. |
| includeExisting DraftInvoiceItems | 196.0 and earlier| Preview Subscription; Update Subscription | Specifies whether to include draft invoice items in subscription previews. Specify it to be true (default) to include draft invoice items in the preview result. Specify it to be false to excludes draft invoice items in the preview result. |
| includeExisting DraftDocItems | 207.0 and later | Preview Subscription; Update Subscription | Specifies whether to include draft invoice items in subscription previews. Specify it to be true (default) to include draft invoice items in the preview result. Specify it to be false to excludes draft invoice items in the preview result. |
| previewType | 196.0 and earlier| Preview Subscription; Update Subscription | The type of preview you will receive. The possible values are InvoiceItem(default), ChargeMetrics, and InvoiceItemChargeMetrics. |
| previewType | 207.0 and later | Preview Subscription; Update Subscription | The type of preview you will receive. The possible values are LegalDoc(default), ChargeMetrics, and LegalDocChargeMetrics. |
| runBilling | 211.0 and later | Create Subscription; Update Subscription; Renew Subscription; Cancel Subscription; Suspend Subscription; Resume Subscription; Create Account|Generates an invoice or credit memo for a subscription. Note: Credit memos are only available if you have the Invoice Settlement feature enabled. |
| invoiceDate | 214.0 and earlier | Invoice and Collect |Date that should appear on the invoice being generated, as yyyy-mm-dd. |
| invoiceTargetDate | 214.0 and earlier | Invoice and Collect |Date through which to calculate charges on this account if an invoice is generated, as yyyy-mm-dd. |
| documentDate | 215.0 and later | Invoice and Collect |Date that should appear on the invoice and credit memo being generated, as yyyy-mm-dd. |
| targetDate | 215.0 and later | Invoice and Collect |Date through which to calculate charges on this account if an invoice or a credit memo is generated, as yyyy-mm-dd. |
| memoItemAmount | 223.0 and earlier | Create credit memo from charge; Create debit memo from charge | Amount of the memo item. |
| amount | 224.0 and later | Create credit memo from charge; Create debit memo from charge | Amount of the memo item. |
| subscriptionNumbers | 222.4 and earlier | Create order | Container for the subscription numbers of the subscriptions in an order. |
| subscriptions | 223.0 and later | Create order | Container for the subscription numbers and statuses in an order. |
| creditTaxItems | 238.0 and earlier | Get credit memo items; Get credit memo item | Container for the taxation items of the credit memo item. |
| taxItems | 238.0 and earlier | Get debit memo items; Get debit memo item | Container for the taxation items of the debit memo item. |
| taxationItems | 239.0 and later | Get credit memo items; Get credit memo item; Get debit memo items; Get debit memo item | Container for the taxation items of the memo item. |
| chargeId | 256.0 and earlier | Create credit memo from charge; Create debit memo from charge | ID of the product rate plan charge that the memo is created from. |
| productRatePlanChargeId | 257.0 and later | Create credit memo from charge; Create debit memo from charge | ID of the product rate plan charge that the memo is created from. |
| comment | 256.0 and earlier | Create credit memo from charge; Create debit memo from charge; Create credit memo from invoice; Create debit memo from invoice; Get credit memo items; Get credit memo item; Get debit memo items; Get debit memo item | Comments about the product rate plan charge, invoice item, or memo item. |
| description | 257.0 and later | Create credit memo from charge; Create debit memo from charge; Create credit memo from invoice; Create debit memo from invoice; Get credit memo items; Get credit memo item; Get debit memo items; Get debit memo item | Description of the the product rate plan charge, invoice item, or memo item. |
Version 207.0 and Later
The response structure of the Preview Subscription and Update Subscription methods are changed. The following invoice related response fields are moved to the invoice container:
amount
amountWithoutTax
taxAmount
invoiceItems
targetDate
chargeMetrics
Zuora Billing Object Model
The following diagram is a high-level view of how key business objects are related to one another within Zuora Billing.
Click the diagram to open it in a new tab and zoom in.
For more information about the different sections of the diagram, see
Zuora Billing business object model.
This diagram is intended to provide a conceptual understanding; it does not illustrate a specific way to integrate with Zuora.
The diagram includes the Orders feature and the Invoice Settlement feature.
If your organization does not use either of these features, see
Zuora Billing business object model prior to Orders and Invoice Settlement
for an alternative diagram.
API Names
You can use the Describe object operation to list the fields of each Zuora object that is available in your tenant. When you call the operation, you must specify the API name of the Zuora object.
The following table provides the API name of each Zuora object:
| Object | API Name |
|-----------------------------------------------|--------------------------------------------|
| Account | Account |
| Accounting Code | AccountingCode |
| Accounting Period | AccountingPeriod |
| Amendment | Amendment |
| Application Group | ApplicationGroup |
| Billing Run | BillingRun - API name used in the Describe object operation, Export ZOQL queries, and Data Query. BillRun - API name used in the Actions. See the CRUD oprations of Bill Run for more information about the BillRun object. BillingRun and BillRun have different fields. |
| Contact | Contact |
| Contact Snapshot | ContactSnapshot |
| Credit Balance Adjustment | CreditBalanceAdjustment |
| Credit Memo | CreditMemo |
| Credit Memo Application | CreditMemoApplication |
| Credit Memo Application Item | CreditMemoApplicationItem |
| Credit Memo Item | CreditMemoItem |
| Credit Memo Part | CreditMemoPart |
| Credit Memo Part Item | CreditMemoPartItem |
| Credit Taxation Item | CreditTaxationItem |
| Custom Exchange Rate | FXCustomRate |
| Debit Memo | DebitMemo |
| Debit Memo Item | DebitMemoItem |
| Debit Taxation Item | DebitTaxationItem |
| Discount Applied Metrics | DiscountAppliedMetrics |
| Entity | Tenant |
| Feature | Feature |
| Gateway Reconciliation Event | PaymentGatewayReconciliationEventLog |
| Gateway Reconciliation Job | PaymentReconciliationJob |
| Gateway Reconciliation Log | PaymentReconciliationLog |
| Invoice | Invoice |
| Invoice Adjustment | InvoiceAdjustment |
| Invoice Item | InvoiceItem |
| Invoice Item Adjustment | InvoiceItemAdjustment |
| Invoice Payment | InvoicePayment |
| Journal Entry | JournalEntry |
| Journal Entry Item | JournalEntryItem |
| Journal Run | JournalRun |
| Order | Order |
| Order Action | OrderAction |
| Order ELP | OrderElp |
| Order Line Items | OrderLineItems |
| Order Item | OrderItem |
| Order MRR | OrderMrr |
| Order Quantity | OrderQuantity |
| Order TCB | OrderTcb |
| Order TCV | OrderTcv |
| Payment | Payment |
| Payment Application | PaymentApplication |
| Payment Application Item | PaymentApplicationItem |
| Payment Method | PaymentMethod |
| Payment Method Snapshot | PaymentMethodSnapshot |
| Payment Method Transaction Log | PaymentMethodTransactionLog |
| Payment Method Update | UpdaterDetail |
| Payment Part | PaymentPart |
| Payment Part Item | PaymentPartItem |
| Payment Run | PaymentRun |
| Payment Transaction Log | PaymentTransactionLog |
| Processed Usage | ProcessedUsage |
| Product | Product |
| Product Feature | ProductFeature |
| Product Rate Plan | ProductRatePlan |
| Product Rate Plan Charge | ProductRatePlanCharge |
| Product Rate Plan Charge Tier | ProductRatePlanChargeTier |
| Rate Plan | RatePlan |
| Rate Plan Charge | RatePlanCharge |
| Rate Plan Charge Tier | RatePlanChargeTier |
| Refund | Refund |
| Refund Application | RefundApplication |
| Refund Application Item | RefundApplicationItem |
| Refund Invoice Payment | RefundInvoicePayment |
| Refund Part | RefundPart |
| Refund Part Item | RefundPartItem |
| Refund Transaction Log | RefundTransactionLog |
| Revenue Charge Summary | RevenueChargeSummary |
| Revenue Charge Summary Item | RevenueChargeSummaryItem |
| Revenue Event | RevenueEvent |
| Revenue Event Credit Memo Item | RevenueEventCreditMemoItem |
| Revenue Event Debit Memo Item | RevenueEventDebitMemoItem |
| Revenue Event Invoice Item | RevenueEventInvoiceItem |
| Revenue Event Invoice Item Adjustment | RevenueEventInvoiceItemAdjustment |
| Revenue Event Item | RevenueEventItem |
| Revenue Event Item Credit Memo Item | RevenueEventItemCreditMemoItem |
| Revenue Event Item Debit Memo Item | RevenueEventItemDebitMemoItem |
| Revenue Event Item Invoice Item | RevenueEventItemInvoiceItem |
| Revenue Event Item Invoice Item Adjustment | RevenueEventItemInvoiceItemAdjustment |
| Revenue Event Type | RevenueEventType |
| Revenue Schedule | RevenueSchedule |
| Revenue Schedule Credit Memo Item | RevenueScheduleCreditMemoItem |
| Revenue Schedule Debit Memo Item | RevenueScheduleDebitMemoItem |
| Revenue Schedule Invoice Item | RevenueScheduleInvoiceItem |
| Revenue Schedule Invoice Item Adjustment | RevenueScheduleInvoiceItemAdjustment |
| Revenue Schedule Item | RevenueScheduleItem |
| Revenue Schedule Item Credit Memo Item | RevenueScheduleItemCreditMemoItem |
| Revenue Schedule Item Debit Memo Item | RevenueScheduleItemDebitMemoItem |
| Revenue Schedule Item Invoice Item | RevenueScheduleItemInvoiceItem |
| Revenue Schedule Item Invoice Item Adjustment | RevenueScheduleItemInvoiceItemAdjustment |
| Subscription | Subscription |
| Subscription Product Feature | SubscriptionProductFeature |
| Taxable Item Snapshot | TaxableItemSnapshot |
| Taxation Item | TaxationItem |
| Updater Batch | UpdaterBatch |
| Usage | Usage |
Welcome to the reference for the Zuora Billing REST API!
To learn about the common use cases of Zuora Billing REST APIs, check out the API Guides.
In addition to Zuora API Reference; Billing, we also provide API references for other Zuora products:
API Reference: Collect
API Reference: Revenue
The Zuora REST API provides a broad set of operations and resources that:
Enable Web Storefront integration from your website.
Support self-service subscriber sign-ups and account management.
Process revenue schedules through custom revenue rule models.
Enable manipulation of most objects in the Zuora Billing Object Model.
Want to share your opinion on how our API works for you? Tell us how you feel about using our API and what we can do to make it better.
Access to the API
If you have a Zuora tenant, you can access the Zuora REST API via one of the following endpoints:
| Tenant | Base URL for REST Endpoints |
|-------------------------|-------------------------|
|US Production | https://rest.zuora.com |
|US API Sandbox | https://rest.apisandbox.zuora.com|
|US Performance Test | https://rest.pt1.zuora.com |
|US Production Copy | Submit a request at Zuora Global Support to enable the Zuora REST API in your tenant and obtain the base URL for REST endpoints. See REST endpoint base URL of Production Copy (Service) Environment for existing and new customers for more information. |
|US Cloud Production | https://rest.na.zuora.com |
|US Cloud API Sandbox | https://rest.sandbox.na.zuora.com |
|US Central Sandbox | https://rest.test.zuora.com |
|EU Production | https://rest.eu.zuora.com |
|EU API Sandbox | https://rest.sandbox.eu.zuora.com |
|EU Central Sandbox | https://rest.test.eu.zuora.com |
The Production endpoint provides access to your live user data. Sandbox tenants are a good place to test code without affecting real-world data. If you would like Zuora to provision a Sandbox tenant for you, contact your Zuora representative for assistance.
If you do not have a Zuora tenant, go to https://www.zuora.com/resource/zuora-test-drive and sign up for a Production Test Drive tenant. The tenant comes with seed data, including a sample product catalog.
API Changelog
You can find the Changelog of the API Reference: Billing in the Zuora Community.
Authentication
OAuth v2.0
Zuora recommends that you use OAuth v2.0 to authenticate to the Zuora REST API. Currently, OAuth is not available in every environment. See Zuora Testing Environments for more information.
Zuora recommends you to create a dedicated API user with API write access on a tenant when authenticating via OAuth, and then create an OAuth client for this user. See Create an API User for how to do this. By creating a dedicated API user, you can control permissions of the API user without affecting other non-API users.
If a user is deactivated, all of the user's OAuth clients will be automatically deactivated.
Authenticating via OAuth requires the following steps:
Create a Client
Generate a Token
Make Authenticated Requests
Create a Client
You must first create an OAuth client in the Zuora UI. To do this, you must be an administrator of your Zuora tenant. This is a one-time operation. You will be provided with a Client ID and a Client Secret. Please note this information down, as it will be required for the next step.
Note: The OAuth client will be owned by a Zuora user account. If you want to perform PUT, POST, or DELETE operations using the OAuth client, the owner of the OAuth client must have a Platform role that includes the "API Write Access" permission.
Generate a Token
After creating a client, you must make a call to obtain a bearer token using the Generate an OAuth token operation. This operation requires the following parameters:
client_id - the Client ID displayed when you created the OAuth client in the previous step
client_secret - the Client Secret displayed when you created the OAuth client in the previous step
granttype - must be set to clientcredentials
Note: The Client ID and Client Secret mentioned above were displayed when you created the OAuth Client in the prior step. The Generate an OAuth token response specifies how long the bearer token is valid for. You should reuse the bearer token until it is expired. When the token is expired, call Generate an OAuth token again to generate a new one.
Make Authenticated Requests
To authenticate subsequent API requests, you must provide a valid bearer token in an HTTP header:
Authorization: Bearer {bearer_token}
If you have Zuora Multi-entity enabled, you need to set an additional header to specify the ID of the entity that you want to access. You can use the scope field in the Generate an OAuth token response to determine whether you need to specify an entity ID.
If the scope field contains more than one entity ID, you must specify the ID of the entity that you want to access. For example, if the scope field contains entity.1a2b7a37-3e7d-4cb3-b0e2-883de9e766cc and entity.c92ed977-510c-4c48-9b51-8d5e848671e9, specify one of the following headers:
Zuora-Entity-Ids: 1a2b7a37-3e7d-4cb3-b0e2-883de9e766cc
Zuora-Entity-Ids: c92ed977-510c-4c48-9b51-8d5e848671e9
Note: For a limited period of time, Zuora will accept the entityId header as an alternative to the Zuora-Entity-Ids header. If you choose to set the entityId header, you must remove all "-" characters from the entity ID in the scope field.
If the scope field contains a single entity ID, you do not need to specify an entity ID.
Other Supported Authentication Schemes
Zuora continues to support the following additional legacy means of authentication:
Use username and password. Include authentication with each request in the header:
apiAccessKeyId
apiSecretAccessKey
Zuora recommends that you create an API user specifically for making API calls. See Create an API User for more information.
Use an authorization cookie. The cookie authorizes the user to make calls to the REST API for the duration specified in Administration > Security Policies > Session timeout. The cookie expiration time is reset with this duration after every call to the REST API. To obtain a cookie, call the Connections resource with the following API user information:
ID
Password
For CORS-enabled APIs only: Include a 'single-use' token in the request header, which re-authenticates the user with each request. See below for more details.
Entity Id and Entity Name
The entityId and entityName parameters are only used for Zuora Multi-entity. These are the legacy parameters that Zuora will only continue to support for a period of time. Zuora recommends you to use the Zuora-Entity-Ids parameter instead.
The entityId and entityName parameters specify the Id and the name of the entity that you want to access, respectively. Note that you must have permission to access the entity.
You can specify either the entityId or entityName parameter in the authentication to access and view an entity.
If both entityId and entityName are specified in the authentication, an error occurs.
If neither entityId nor entityName is specified in the authentication, you will log in to the entity in which your user account is created.
To get the entity Id and entity name, you can use the GET Entities REST call. For more information, see API User Authentication.
Token Authentication for CORS-Enabled APIs
The CORS mechanism enables REST API calls to Zuora to be made directly from your customer's browser, with all credit card and security information transmitted directly to Zuora. This minimizes your PCI compliance burden, allows you to implement advanced validation on your payment forms, and makes your payment forms look just like any other part of your website.
For security reasons, instead of using cookies, an API request via CORS uses tokens for authentication.
The token method of authentication is only designed for use with requests that must originate from your customer's browser; it should not be considered a replacement to the existing cookie authentication mechanism.
See Zuora CORS REST for details on how CORS works and how you can begin to implement customer calls to the Zuora REST APIs. See HMAC Signatures for details on the HMAC method that returns the authentication token.
Requests and Responses
Request IDs
As a general rule, when asked to supply a "key" for an account or subscription (accountKey, account-key, subscriptionKey, subscription-key), you can provide either the actual ID or the number of the entity.
HTTP Request Body
Most of the parameters and data accompanying your requests will be contained in the body of the HTTP request.
The Zuora REST API accepts JSON in the HTTP request body. No other data format (e.g., XML) is supported.
Data Type
(Actions and CRUD operations only) We recommend that you do not specify the decimal values with quotation marks, commas, and spaces. Use characters of +-0-9.eE, for example, 5, 1.9, -8.469, and 7.7e2. Also, Zuora does not convert currencies for decimal values.
Testing a Request
Use a third party client, such as curl, Postman, or Advanced REST Client, to test the Zuora REST API.
You can test the Zuora REST API from the Zuora API Sandbox or Production tenants. If connecting to Production, bear in mind that you are working with your live production data, not sample data or test data.
Testing with Credit Cards
Sooner or later it will probably be necessary to test some transactions that involve credit cards. For suggestions on how to handle this, see [Going Live With Your Payment Gateway](https://knowledgecenter.zuora.com/CBBilling/MPaymentGateways/CManagingPaymentGateways/BGoingLivePaymentGateways#TestingwithCreditCards "CZuoraUserGuides/ABillingandPayments/MPaymentGateways/CManagingPaymentGateways/BGoingLivePaymentGateways#TestingwithCredit_Cards"
).
Concurrent Request Limits
Zuora enforces tenant-level concurrent request limits. See Concurrent Request Limits for more information.
Timeout Limit
If a request does not complete within 120 seconds, the request times out and Zuora returns a Gateway Timeout error.
Error Handling
If a request to Zuora Billing REST API with an endpoint starting with /v1 (except Actions and CRUD operations) fails, the response will contain an eight-digit error code with a corresponding error message to indicate the details of the error.
The following code snippet is a sample error response that contains an error code and message pair:
The success field indicates whether the API request has succeeded. The processId field is a Zuora internal ID that you can provide to Zuora Global Support for troubleshooting purposes.
The reasons field contains the actual error code and message pair. The error code begins with 5 or 6 means that you encountered a certain issue that is specific to a REST API resource in Zuora Billing. For example, 53100320 indicates that an invalid value is specified for the termType field of the subscription object.
The error code beginning with 9 usually indicates that an authentication-related issue occurred, and it can also indicate other unexpected errors depending on different cases. For example, 90000011 indicates that an invalid credential is provided in the request header.
When troubleshooting the error, you can divide the error code into two components: REST API resource code and error category code. See the following Zuora error code sample:
Note: Zuora determines resource codes based on the request payload. Therefore, if GET and DELETE requests that do not contain payloads fail, you will get 500000 as the resource code, which indicates an unknown object and an unknown field.
The error category code of these requests is valid and follows the rules described in the Error Category Code section.
In such case, you can refer to the returned error message to troubleshoot.
REST API Resource Code
The 6-digit resource code indicates the REST API resource, typically a field of a Zuora object, on which the issue occurs. In the preceding example, 531003 refers to the termType field of the subscription object.
The value range for all REST API resource codes is from 500000 to 679999. See Resource Codes in the Knowledge Center for a full list of resource codes.
Error Category Code
The 2-digit error category code identifies the type of error, for example, resource not found or missing required field.
The following table describes all error categories and the corresponding resolution:
| Code | Error category | Description | Resolution |
|:--------|:--------|:--------|:--------|
| 10 | Permission or access denied | The request cannot be processed because a certain tenant or user permission is missing. | Check the missing tenant or user permission in the response message and contact Zuora Global Support for enablement. |
| 11 | Authentication failed | Authentication fails due to invalid API authentication credentials. | Ensure that a valid API credential is specified. |
| 20 | Invalid format or value | The request cannot be processed due to an invalid field format or value. | Check the invalid field in the error message, and ensure that the format and value of all fields you passed in are valid. |
| 21 | Unknown field in request | The request cannot be processed because an unknown field exists in the request body. | Check the unknown field name in the response message, and ensure that you do not include any unknown field in the request body. |
| 22 | Missing required field | The request cannot be processed because a required field in the request body is missing. | Check the missing field name in the response message, and ensure that you include all required fields in the request body. |
| 30 | Rule restriction | The request cannot be processed due to the violation of a Zuora business rule. | Check the response message and ensure that the API request meets the specified business rules. |
| 40 | Not found | The specified resource cannot be found. | Check the response message and ensure that the specified resource exists in your Zuora tenant. |
| 45 | Unsupported request | The requested endpoint does not support the specified HTTP method. | Check your request and ensure that the endpoint and method matches. |
| 50 | Locking contention | This request cannot be processed because the objects this request is trying to modify are being modified by another API request, UI operation, or batch job process. | Resubmit the request first to have another try. If this error still occurs, contact Zuora Global Support with the returned Zuora-Request-Id value in the response header for assistance. |
| 60 | Internal error | The server encounters an internal error. | Contact Zuora Global Support with the returned Zuora-Request-Id value in the response header for assistance. |
| 70 | Request exceeded limit | The total number of concurrent requests exceeds the limit allowed by the system. | Resubmit the request after the number of seconds specified by the Retry-After value in the response header. Check Concurrent request limits for details about Zuora’s concurrent request limit policy. |
| 90 | Malformed request | The request cannot be processed due to JSON syntax errors. | Check the syntax error in the JSON request body and ensure that the request is in the correct JSON format. |
| 99 | Integration error | The server encounters an error when communicating with an external system, for example, payment gateway, tax engine provider. | Check the response message and take action accordingly. |
Pagination
When retrieving information (using GET methods), the optional pageSize query parameter sets the maximum number of rows to return in a response. The maximum is 40; larger values are treated as 40. If this value is empty or invalid, pageSize typically defaults to 10.
The default value for the maximum number of rows retrieved can be overridden at the method level.
If more rows are available, the response will include a nextPage element, which contains a URL for requesting the next page. If this value is not provided, no more rows are available. No "previous page" element is explicitly provided; to support backward paging, use the previous call.
Array Size
For data items that are not paginated, the REST API supports arrays of up to 300 rows. Thus, for instance, repeated pagination can retrieve thousands of customer accounts, but within any account an array of no more than 300 rate plans is returned.
API Versions
The Zuora REST API are version controlled. Versioning ensures that Zuora REST API changes are backward compatible. Zuora uses a major and minor version nomenclature to manage changes. By specifying a version in a REST request, you can get expected responses regardless of future changes to the API.
Major Version
The major version number of the REST API appears in the REST URL. Currently, Zuora only supports the v1 major version. For example, POST https://rest.zuora.com/v1/subscriptions.
Minor Version
Zuora uses minor versions for the REST API to control small changes. For example, a field in a REST method is deprecated and a new field is used to replace it.
Some fields in the REST methods are supported as of minor versions. If a field is not noted with a minor version, this field is available for all minor versions. If a field is noted with a minor version, this field is in version control. You must specify the supported minor version in the request header to process without an error.
If a field is in version control, it is either with a minimum minor version or a maximum minor version, or both of them. You can only use this field with the minor version between the minimum and the maximum minor versions. For example, the invoiceCollect field in the POST Subscription method is in version control and its maximum minor version is 189.0. You can only use this field with the minor version 189.0 or earlier.
If you specify a version number in the request header that is not supported, Zuora will use the minimum minor version of the REST API. In our REST API documentation, if a field or feature requires a minor version number, we note that in the field description.
You only need to specify the version number when you use the fields require a minor version. To specify the minor version, set the zuora-version parameter to the minor version number in the request header for the request call. For example, the collect field is in 196.0 minor version. If you want to use this field for the POST Subscription method, set the zuora-version parameter to 196.0 in the request header. The zuora-version parameter is case sensitive.
For all the REST API fields, by default, if the minor version is not specified in the request header, Zuora will use the minimum minor version of the REST API to avoid breaking your integration.
Minor Version History
The supported minor versions are not serial. This section documents the changes made to each Zuora REST API minor version.
The following table lists the supported versions and the fields that have a Zuora REST API minor version.
| Fields | Minor Version | REST Methods | Description |
|:--------|:--------|:--------|:--------|
| invoiceCollect | 189.0 and earlier | Create Subscription; Update Subscription; Renew Subscription; Cancel Subscription; Suspend Subscription; Resume Subscription; Create Account|Generates an invoice and collects a payment for a subscription. |
| collect | 196.0 and later | Create Subscription; Update Subscription; Renew Subscription; Cancel Subscription; Suspend Subscription; Resume Subscription; Create Account|Collects an automatic payment for a subscription. |
| invoice | 196.0 and 207.0| Create Subscription; Update Subscription; Renew Subscription; Cancel Subscription; Suspend Subscription; Resume Subscription; Create Account|Generates an invoice for a subscription. |
| invoiceTargetDate | 196.0 and earlier | Preview Subscription |Date through which charges are calculated on the invoice, as yyyy-mm-dd. |
| invoiceTargetDate | 207.0 and earlier | Create Subscription; Update Subscription; Renew Subscription; Cancel Subscription; Suspend Subscription; Resume Subscription; Create Account|Date through which charges are calculated on the invoice, as yyyy-mm-dd. |
| targetDate | 207.0 and later | Preview Subscription |Date through which charges are calculated on the invoice, as yyyy-mm-dd. |
| targetDate | 211.0 and later | Create Subscription; Update Subscription; Renew Subscription; Cancel Subscription; Suspend Subscription; Resume Subscription; Create Account|Date through which charges are calculated on the invoice, as yyyy-mm-dd. |
| includeExisting DraftInvoiceItems | 196.0 and earlier| Preview Subscription; Update Subscription | Specifies whether to include draft invoice items in subscription previews. Specify it to be true (default) to include draft invoice items in the preview result. Specify it to be false to excludes draft invoice items in the preview result. |
| includeExisting DraftDocItems | 207.0 and later | Preview Subscription; Update Subscription | Specifies whether to include draft invoice items in subscription previews. Specify it to be true (default) to include draft invoice items in the preview result. Specify it to be false to excludes draft invoice items in the preview result. |
| previewType | 196.0 and earlier| Preview Subscription; Update Subscription | The type of preview you will receive. The possible values are InvoiceItem(default), ChargeMetrics, and InvoiceItemChargeMetrics. |
| previewType | 207.0 and later | Preview Subscription; Update Subscription | The type of preview you will receive. The possible values are LegalDoc(default), ChargeMetrics, and LegalDocChargeMetrics. |
| runBilling | 211.0 and later | Create Subscription; Update Subscription; Renew Subscription; Cancel Subscription; Suspend Subscription; Resume Subscription; Create Account|Generates an invoice or credit memo for a subscription. Note: Credit memos are only available if you have the Invoice Settlement feature enabled. |
| invoiceDate | 214.0 and earlier | Invoice and Collect |Date that should appear on the invoice being generated, as yyyy-mm-dd. |
| invoiceTargetDate | 214.0 and earlier | Invoice and Collect |Date through which to calculate charges on this account if an invoice is generated, as yyyy-mm-dd. |
| documentDate | 215.0 and later | Invoice and Collect |Date that should appear on the invoice and credit memo being generated, as yyyy-mm-dd. |
| targetDate | 215.0 and later | Invoice and Collect |Date through which to calculate charges on this account if an invoice or a credit memo is generated, as yyyy-mm-dd. |
| memoItemAmount | 223.0 and earlier | Create credit memo from charge; Create debit memo from charge | Amount of the memo item. |
| amount | 224.0 and later | Create credit memo from charge; Create debit memo from charge | Amount of the memo item. |
| subscriptionNumbers | 222.4 and earlier | Create order | Container for the subscription numbers of the subscriptions in an order. |
| subscriptions | 223.0 and later | Create order | Container for the subscription numbers and statuses in an order. |
| creditTaxItems | 238.0 and earlier | Get credit memo items; Get credit memo item | Container for the taxation items of the credit memo item. |
| taxItems | 238.0 and earlier | Get debit memo items; Get debit memo item | Container for the taxation items of the debit memo item. |
| taxationItems | 239.0 and later | Get credit memo items; Get credit memo item; Get debit memo items; Get debit memo item | Container for the taxation items of the memo item. |
| chargeId | 256.0 and earlier | Create credit memo from charge; Create debit memo from charge | ID of the product rate plan charge that the memo is created from. |
| productRatePlanChargeId | 257.0 and later | Create credit memo from charge; Create debit memo from charge | ID of the product rate plan charge that the memo is created from. |
| comment | 256.0 and earlier | Create credit memo from charge; Create debit memo from charge; Create credit memo from invoice; Create debit memo from invoice; Get credit memo items; Get credit memo item; Get debit memo items; Get debit memo item | Comments about the product rate plan charge, invoice item, or memo item. |
| description | 257.0 and later | Create credit memo from charge; Create debit memo from charge; Create credit memo from invoice; Create debit memo from invoice; Get credit memo items; Get credit memo item; Get debit memo items; Get debit memo item | Description of the the product rate plan charge, invoice item, or memo item. |
Version 207.0 and Later
The response structure of the Preview Subscription and Update Subscription methods are changed. The following invoice related response fields are moved to the invoice container:
amount
amountWithoutTax
taxAmount
invoiceItems
targetDate
chargeMetrics
Zuora Billing Object Model
The following diagram is a high-level view of how key business objects are related to one another within Zuora Billing.
Click the diagram to open it in a new tab and zoom in.
For more information about the different sections of the diagram, see
Zuora Billing business object model.
This diagram is intended to provide a conceptual understanding; it does not illustrate a specific way to integrate with Zuora.
The diagram includes the Orders feature and the Invoice Settlement feature.
If your organization does not use either of these features, see
Zuora Billing business object model prior to Orders and Invoice Settlement
for an alternative diagram.
API Names
You can use the Describe object operation to list the fields of each Zuora object that is available in your tenant. When you call the operation, you must specify the API name of the Zuora object.
The following table provides the API name of each Zuora object:
| Object | API Name |
|-----------------------------------------------|--------------------------------------------|
| Account | Account |
| Accounting Code | AccountingCode |
| Accounting Period | AccountingPeriod |
| Amendment | Amendment |
| Application Group | ApplicationGroup |
| Billing Run | BillingRun - API name used in the Describe object operation, Export ZOQL queries, and Data Query. BillRun - API name used in the Actions. See the CRUD oprations of Bill Run for more information about the BillRun object. BillingRun and BillRun have different fields. |
| Contact | Contact |
| Contact Snapshot | ContactSnapshot |
| Credit Balance Adjustment | CreditBalanceAdjustment |
| Credit Memo | CreditMemo |
| Credit Memo Application | CreditMemoApplication |
| Credit Memo Application Item | CreditMemoApplicationItem |
| Credit Memo Item | CreditMemoItem |
| Credit Memo Part | CreditMemoPart |
| Credit Memo Part Item | CreditMemoPartItem |
| Credit Taxation Item | CreditTaxationItem |
| Custom Exchange Rate | FXCustomRate |
| Debit Memo | DebitMemo |
| Debit Memo Item | DebitMemoItem |
| Debit Taxation Item | DebitTaxationItem |
| Discount Applied Metrics | DiscountAppliedMetrics |
| Entity | Tenant |
| Feature | Feature |
| Gateway Reconciliation Event | PaymentGatewayReconciliationEventLog |
| Gateway Reconciliation Job | PaymentReconciliationJob |
| Gateway Reconciliation Log | PaymentReconciliationLog |
| Invoice | Invoice |
| Invoice Adjustment | InvoiceAdjustment |
| Invoice Item | InvoiceItem |
| Invoice Item Adjustment | InvoiceItemAdjustment |
| Invoice Payment | InvoicePayment |
| Journal Entry | JournalEntry |
| Journal Entry Item | JournalEntryItem |
| Journal Run | JournalRun |
| Order | Order |
| Order Action | OrderAction |
| Order ELP | OrderElp |
| Order Line Items | OrderLineItems |
| Order Item | OrderItem |
| Order MRR | OrderMrr |
| Order Quantity | OrderQuantity |
| Order TCB | OrderTcb |
| Order TCV | OrderTcv |
| Payment | Payment |
| Payment Application | PaymentApplication |
| Payment Application Item | PaymentApplicationItem |
| Payment Method | PaymentMethod |
| Payment Method Snapshot | PaymentMethodSnapshot |
| Payment Method Transaction Log | PaymentMethodTransactionLog |
| Payment Method Update | UpdaterDetail |
| Payment Part | PaymentPart |
| Payment Part Item | PaymentPartItem |
| Payment Run | PaymentRun |
| Payment Transaction Log | PaymentTransactionLog |
| Processed Usage | ProcessedUsage |
| Product | Product |
| Product Feature | ProductFeature |
| Product Rate Plan | ProductRatePlan |
| Product Rate Plan Charge | ProductRatePlanCharge |
| Product Rate Plan Charge Tier | ProductRatePlanChargeTier |
| Rate Plan | RatePlan |
| Rate Plan Charge | RatePlanCharge |
| Rate Plan Charge Tier | RatePlanChargeTier |
| Refund | Refund |
| Refund Application | RefundApplication |
| Refund Application Item | RefundApplicationItem |
| Refund Invoice Payment | RefundInvoicePayment |
| Refund Part | RefundPart |
| Refund Part Item | RefundPartItem |
| Refund Transaction Log | RefundTransactionLog |
| Revenue Charge Summary | RevenueChargeSummary |
| Revenue Charge Summary Item | RevenueChargeSummaryItem |
| Revenue Event | RevenueEvent |
| Revenue Event Credit Memo Item | RevenueEventCreditMemoItem |
| Revenue Event Debit Memo Item | RevenueEventDebitMemoItem |
| Revenue Event Invoice Item | RevenueEventInvoiceItem |
| Revenue Event Invoice Item Adjustment | RevenueEventInvoiceItemAdjustment |
| Revenue Event Item | RevenueEventItem |
| Revenue Event Item Credit Memo Item | RevenueEventItemCreditMemoItem |
| Revenue Event Item Debit Memo Item | RevenueEventItemDebitMemoItem |
| Revenue Event Item Invoice Item | RevenueEventItemInvoiceItem |
| Revenue Event Item Invoice Item Adjustment | RevenueEventItemInvoiceItemAdjustment |
| Revenue Event Type | RevenueEventType |
| Revenue Schedule | RevenueSchedule |
| Revenue Schedule Credit Memo Item | RevenueScheduleCreditMemoItem |
| Revenue Schedule Debit Memo Item | RevenueScheduleDebitMemoItem |
| Revenue Schedule Invoice Item | RevenueScheduleInvoiceItem |
| Revenue Schedule Invoice Item Adjustment | RevenueScheduleInvoiceItemAdjustment |
| Revenue Schedule Item | RevenueScheduleItem |
| Revenue Schedule Item Credit Memo Item | RevenueScheduleItemCreditMemoItem |
| Revenue Schedule Item Debit Memo Item | RevenueScheduleItemDebitMemoItem |
| Revenue Schedule Item Invoice Item | RevenueScheduleItemInvoiceItem |
| Revenue Schedule Item Invoice Item Adjustment | RevenueScheduleItemInvoiceItemAdjustment |
| Subscription | Subscription |
| Subscription Product Feature | SubscriptionProductFeature |
| Taxable Item Snapshot | TaxableItemSnapshot |
| Taxation Item | TaxationItem |
| Updater Batch | UpdaterBatch |
| Usage | Usage |
GOV.UK Pay API
payments.service.gov.uk
GOV.UK Pay API (This version is no longer maintained. See openapi/publicapi_spec.json for latest API specification)
Swiss NextGen Banking API-Framework
Summary
The Swiss NextGen API is based on the NextGenPSD2 Framework Version 1.3.4 of the Berlin Group which offers a modern, open, harmonised and interoperable set of
Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely.
The NextGen Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards
in Europe and, aligned with the goals of the Euro Retail Payments Board,
enables European banking customers to benefit from innovative products and services ('Banking as a Service')
by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data.
The Swiss edtion refines the message formats specific to Switzerland and defines some matching examples.
The possible Approaches are:
Redirect SCA Approach
(Not recommended by obp.ch community) OAuth SCA Approach
(Not recommended by obp.ch community) Decoupled SCA Approach
(Not recommended by obp.ch community) Embedded SCA Approach without SCA method
(Not recommended by obp.ch community) Embedded SCA Approach with only one SCA method available
(Not recommended by obp.ch community) Embedded SCA Approach with Selection of a SCA method
Not every message defined in this API definition is necessary for all approaches.
Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional
Therefore for a particular implementation of a compliant API it is only necessary to support
a certain subset of the methods defined in this API definition.
**Please have a look at the implementation guidelines if you are not sure
which message has to be used for the approach you are going to use.**
Some General Remarks Related to this version of the OpenAPI Specification:
This API definition is based on the Implementation Guidelines of the Berlin Group API.
It is not a replacement in any sense.
The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group API.
This API definition contains the REST-API for requests from the PISP to the ASPSP.
This API definition contains the messages for all different approaches defined in the Implementation Guidelines.
According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md]
"If in is "header" and the name field is "Accept", "Content-Type" or "Authorization", the parameter definition SHALL be ignored."
The element "Accept" will not be defined in this file at any place.
The elements "Content-Type" and "Authorization" are implicitly defined by the OpenApi tags "content" and "security".
There are several predefined types which might occur in payment initiation messages,
but are not used in the standard JSON messages in the Implementation Guidelines.
Therefore they are not used in the corresponding messages in this file either.
We added them for the convenience of the user.
If there is a payment product, which needs these fields, one can easily use the predefined types.
But the ASPSP need not to accept them in general.
**We omit the definition of all standard HTTP header elements (mandatory/optional/conditional)
except they are mentioned in the Implementation Guidelines.**
Therefore the implementer might add these in his own realisation of a comlient API in addition to the elements defined in this file.
General Remarks on Data Types
The Berlin Group definition of UTF-8 strings in context of the API have to support at least the following characters
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
/ - ? : ( ) . , ' +
Space
The Swiss NextGen API is based on the NextGenPSD2 Framework Version 1.3.4 of the Berlin Group which offers a modern, open, harmonised and interoperable set of
Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely.
The NextGen Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards
in Europe and, aligned with the goals of the Euro Retail Payments Board,
enables European banking customers to benefit from innovative products and services ('Banking as a Service')
by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data.
The Swiss edtion refines the message formats specific to Switzerland and defines some matching examples.
The possible Approaches are:
Redirect SCA Approach
(Not recommended by obp.ch community) OAuth SCA Approach
(Not recommended by obp.ch community) Decoupled SCA Approach
(Not recommended by obp.ch community) Embedded SCA Approach without SCA method
(Not recommended by obp.ch community) Embedded SCA Approach with only one SCA method available
(Not recommended by obp.ch community) Embedded SCA Approach with Selection of a SCA method
Not every message defined in this API definition is necessary for all approaches.
Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional
Therefore for a particular implementation of a compliant API it is only necessary to support
a certain subset of the methods defined in this API definition.
**Please have a look at the implementation guidelines if you are not sure
which message has to be used for the approach you are going to use.**
Some General Remarks Related to this version of the OpenAPI Specification:
This API definition is based on the Implementation Guidelines of the Berlin Group API.
It is not a replacement in any sense.
The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group API.
This API definition contains the REST-API for requests from the PISP to the ASPSP.
This API definition contains the messages for all different approaches defined in the Implementation Guidelines.
According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md]
"If in is "header" and the name field is "Accept", "Content-Type" or "Authorization", the parameter definition SHALL be ignored."
The element "Accept" will not be defined in this file at any place.
The elements "Content-Type" and "Authorization" are implicitly defined by the OpenApi tags "content" and "security".
There are several predefined types which might occur in payment initiation messages,
but are not used in the standard JSON messages in the Implementation Guidelines.
Therefore they are not used in the corresponding messages in this file either.
We added them for the convenience of the user.
If there is a payment product, which needs these fields, one can easily use the predefined types.
But the ASPSP need not to accept them in general.
**We omit the definition of all standard HTTP header elements (mandatory/optional/conditional)
except they are mentioned in the Implementation Guidelines.**
Therefore the implementer might add these in his own realisation of a comlient API in addition to the elements defined in this file.
General Remarks on Data Types
The Berlin Group definition of UTF-8 strings in context of the API have to support at least the following characters
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
/ - ? : ( ) . , ' +
Space
IBKR 3rd Party Web API
interactivebrokers.com
Interactive Brokers Web API for 3rd Party Companies
Tradematic Cloud API
tradematic.com
Overview
Tradematic Cloud is a trading infrastructure for building investment services.
It’s a trading engine + API + ready-made adapters to stock and forex brokers, crypto exchanges, and market data providers.
You can use it as a cloud API, or you can deploy it on your servers.
How to use Tradematic Cloud API
Sign up at tradematic.cloud. After signing up, you will receive your API key.
Authorization
Add the 'X-API-KEY' header with your API key to each request.
Examples of writing code with Tradematic Cloud API
Examples are available at tradematic.cloud.
Swagger (.yaml) File
Swagger (.yaml) file can be found here.
Tradematic Cloud is a trading infrastructure for building investment services.
It’s a trading engine + API + ready-made adapters to stock and forex brokers, crypto exchanges, and market data providers.
You can use it as a cloud API, or you can deploy it on your servers.
How to use Tradematic Cloud API
Sign up at tradematic.cloud. After signing up, you will receive your API key.
Authorization
Add the 'X-API-KEY' header with your API key to each request.
Examples of writing code with Tradematic Cloud API
Examples are available at tradematic.cloud.
Swagger (.yaml) File
Swagger (.yaml) file can be found here.
Billingo API v3
This is a Billingo API v3 documentation. Our API based on REST software architectural style. API has resource-oriented URLs, accepts JSON-encoded request bodies and returns JSON-encoded responses. To use this API you have to generate a new API key on our site. After that, you can test your API key on this page.