Callout security

Zuora's callout security measures are built on the combination of HTTPS delivery and they need to authenticate with Zuora API's to retrieve follow-on information.

Zuora will make a callout over HTTPS to a customer-designated URL. HTTPS transport guarantees that no one will intercept the communication. The data transferred over the URL is non-sensitive data, typically an ID for the specific event reported. The recipient of the callout notification will then need to authenticate back with Zuora to retrieve additional information about the event.

Callout header

Zuora adds the following header fields to callout notifications by default. You can leverage these header fieldss to trace callout notifications.

In addition, you can create custom callout headers in callout templates to deliver additional information in callout notifications.

User locale and data format

The user locale setting provides an override tenant locale setting. You can change the locale according to your preferred format for display of date and dateTime fields.

Callout notification timeout

Every callout has a total of 25 seconds before timing out:

• 10 seconds to establish socket connection

• 15 seconds for data transfer

Currently, the timeout limit cannot be changed. You can change the maximum number of attempts, as well as the time interval between each attempt. For more information, see Configure callout settings.

Zuora recommends creating asynchronous jobs that run in the background and are independent of callout transactions from Zuora. This is to ensure that your processes are not dependent on the timeframe in which Zuora keeps connections open.

Callout response codes

Zuora uses the HTTP response code to determine whether to retry callouts. Zuora only retries a callout if the response code is one of the following:

• 1xx

• 403

• 408

• 429

• 5xx

• Negative

Note that if the custom request body of callout notifications is invalid, a -2000 response code is returned, and Zuora will neither send the callout notification nor retry it. For more information about Custom request entity body, see Create a callout template.

Additionally, if Confirm success by parsing response content is enabled in callout settings, Zuora retries a callout if the response code is 200 and the response body contains a success field that is set to false. See Configure callout settings for more information.

Message sequence for callout basic authentication

The basic authentication for Zuora callout notifications is compliant with the HTTP Authentication (RFC 7235) and Basic HTTP Authentication (RFC 7617) specifications.

When using Basic authentication in callout notifications, Zuora transmits credentials with the Authorization field in HTTP request headers. The format of the Authorization field is as follows:

Authorization: Basic <username:password>

The <username:password> is a base64-encoded string.

The default message sequence for callout notifications with basic authentication is as follows:

1. Zuora sends an HTTP request to the callout receiver without the Authorization field.

2. The callout receiver responds to Zuora with a 401(Unauthorized) response that has a WWW-Authenticate header field with a realm value indicating the protection scope.

3. Zuora sends to the callout receiver a second request that has an Authorization header field containing valid credentials.

4. The callout receiver responds to Zuora with a 200 response upon validation of credentials.

If you want Zuora to provide the Authorization field in the first HTTP request, enable the Enable Preemptive Authentication setting in the associated callout template. For more information, see Create a callout template.

Note

Zuora notification system processes the events in the same order in which they are triggered. The timing and order of callout notifications depend on various factors, such as callout retries, concurrency, and network latency. But Zuora guarantees the best performance possible with the right performance boosters and tuning.