Skip to main content

Autotask Exceptions

When MSPintegrations calls the Autotask API and the call fails or is rejected, MSPintegrations generates an exception. This page covers what causes Autotask exceptions, which ones MSPintegrations retries, and what the Suppress Autotask API exceptions checkbox does.

For how exceptions work across the whole system, see Exceptions and Retries.

Common Causes​

CauseWhat it means
Autotask API is unreachableAutotask is down, in maintenance, or the connection timed out
API threshold exceededYour Autotask database used its allowed API requests for the current period
Invalid credentialsThe Autotask API user stored in MSPintegrations is wrong, disabled, or its password expired
Rejected dataThe call was missing a required field, or contained a value Autotask would not accept
Insufficient permissionsThe Autotask API user's security level does not allow the operation

What MSPintegrations Retries​

Autotask errors split cleanly into the two categories described in Exceptions and Retries.

Retried automatically:

  • Autotask API unreachable, offline, or in maintenance
  • Request timeouts and dropped connections
  • API request and thread threshold errors
  • Attachment quota exhaustion

These are transient. MSPintegrations pauses the workflow and keeps trying, so a short Autotask outage delays your automation rather than failing it.

Not retried:

  • Invalid credentials, disabled accounts, and expired passwords
  • Invalid integration codes
  • Data Autotask rejected as invalid
  • Permission denied for the entity type
  • Attachments that are too large

Sending these again produces the same rejection, so MSPintegrations fails immediately.

MSPintegrations slows down before you hit the threshold

When your Autotask API usage passes 80% of your threshold, MSPintegrations pauses affected actions for about five minutes and records a warning in history rather than spending your remaining requests. The workflow resumes on its own. This pause is not a failure and does not count against retry limits.

See API Threshold.

The Suppress Autotask API Exceptions Checkbox​

Every Autotask action has a Suppress Autotask API exceptions checkbox in its Advanced section. It is unchecked by default.

The label in the console reads:

This determines whether the remaining actions will be processed if the Autotask API returns an error response to this API call. If checked, the workflow will continue to be processed even if this API call fails. Use this option sparingly and carefully.

What it does when enabled​

Unchecked (default)Checked
Error recorded in historyYesYes
Workflow stopsYesNo
Run marked FailedYesNo
Notification email sentYesNo
Action's resultEmptyEmpty

Suppression does not hide the error. The failure is still written to the processing log in red, with the message Autotask returned and the data MSPintegrations sent. What changes is that the workflow keeps going and nobody gets emailed.

What it does not do​

It does not affect retries. Suppression applies only to errors that cannot be retried. A transient Autotask error is retried normally whether or not the box is checked.

It does not give the action a result. The action's output variable is empty. Any later step that depends on that output must handle the empty value, or it will fail in a more confusing way than the original error would have.

When to use it​

Enable it when a failure is an expected outcome you have deliberately planned for. The clearest case is a loop where individual items may legitimately be rejected and you want the remaining items processed anyway.

Leave it unchecked everywhere else. If an action fails often enough that suppressing it seems attractive, the configuration usually needs attention instead. Suppressing an exception you do not understand converts a loud failure into a silent one.

Diagnosing an Autotask Exception​

Autotask error messages are passed through to you unchanged, so the processing log usually names the problem directly. Open the failing step in history and read the response Autotask returned.

Fix the rule, then use Play on the history entry to replay the same trigger through your updated configuration.