Skip to main content

Developing a Backup Plan

With the integration up and running, it's important to establish a backup plan in case any element doesn't behave as expected. In short, plan out how to keep critical business processes running in case of any contingency. It’s also important to plan how to recover from unexpected interruptions, and the CAS API's Replay feature will be a useful tool for that operation.

Delivery Failures

The most common issue encountered by CAS API users is a delivery failure. A delivery failure occurs when the CAS API can't deliver a payload to the user-specified destination. The common causes of these delivery failures are incorrect user account credentials, unavailability of the destination due to a server outage, and unavailability of the destination due to throttling of incoming requests. To put it simply, sometimes the CAS API can't reach the destination to drop off files, despite its best efforts. In the event of a delivery failure, the CAS API will do two things:

  • Delivery failure email notifications
    • The email address attached to the subscription (see subscription creation notes above) will receive an email notification for each payload that the CAS API fails to deliver. The email notification will include some details about the payload it was trying to deliver, the event that triggered the delivery, the destination it was trying to deliver to, and the nature of the failure itself. It is a best practice to review these notifications and double-check your destination to ensure it is properly configured to receive payloads from the CAS API.
  • CAS API automatic retry
    • Whenever the CAS API fails to deliver a payload, the CAS API's automatic retry feature kicks in. If the CAS API can't deliver to the user-specified destination, it waits a few seconds, and then tries again. If it fails again, it will wait a little longer, and then try again another time. The CAS API will repeatedly retry in this manner, waiting longer each time, for a period of about 3 1/2 days. In other words, the CAS API won't give up until it's tried its hardest to deliver the payload. With each retry, the CAS API will send an additional email notification if the delivery fails (see above). There should be sufficient warning when a destination becomes unreachable for you to resolve the issue with the destination so that the CAS API can successfully deliver application data and documents. Experience has shown that, by and large, delivery failures are intermittent, and the CAS API successfully delivers payloads on a retry attempt.

Import failures

Review the Slate Knowledge Base for information on reviewing and reloading sources.

Catching up after an interruption: CAS API Replay

Whenever an unexpected interruption to your data integration is encountered, first restore the integration to functionality, then catch up on any missed payloads. The CAS API's Replay feature makes that easy to do.

What does the CAS API Replay do?

A CAS API Replay redelivers payloads for existing subscriptions that would have been delivered during a set interval of time.

How do I use the CAS API Replay?

Identify the affected period and trigger a Replay on your subscription for that period. To create a Replay job:

  2. Specify in the body of that request:
    • the ID of your subscription, and
    • the affected time period for which you want payloads to be redelivered. The maximum possible interval for each replay is 30 days. If your outage extended longer than 30 days, you will need to run multiple replays, one for each separate interval of 30 days.
    • The body of the replay creation request should look something like this:
"fromDate" : "2020-09-01",
"toDate" : "2020-10-01",
"subscription": {
"subscriptionId": 216

For more details on the Relay endpoints, review the CAS API Technical Documentation.

  • Was this article helpful?