Errors, Execution States, and Limits

Use the HTTP response and execution result to understand whether a request was accepted, a report ran successfully or further investigation is needed.

HTTP outcomes

Status	What to do
200	Read the selected operation’s response, including an empty body where documented.
400	Inspect the rejection and correct the request.
401	Check credentials, token extraction, bearer header and expiry.
403	Check permissions for the operation and resource.
500	Inspect details; input, database, permission and reporting failures can use this status.

An error body is not always JSON. Inspect status, content type and body presence before parsing. Keep the original error if body parsing fails. A 500 response is not automatically transient.

Error response examples

A message error can look like this illustrative response:

{"Message":"The request is invalid."}

Exception responses can also contain ExceptionMessage, ExceptionType or a stack trace. These fields are conditional. Store diagnostics securely and give end users a clear action without exposing raw infrastructure details.

Successful response shapes

Operation	Successful representation
`Ping`	Number `1`.
`IsSchedulerRunning`	Boolean.
`GetConfigPath`	JSON string.
`SingleSchedule/Clone`	Integer ID.
`SingleSchedule/Create`	Object containing `UniqueId`.
`SingleSchedule/Update`	Empty body.

Use each operation’s schema rather than forcing all responses into one wrapper object.

Execution acceptance and results

ExecuteScheduleAsync returns ExecutionId to acknowledge submission. ExecuteSchedule returns a result that must be inspected even with HTTP 200.

Keep the stored schedule ID, execution ID and process ID separate. For processes, retain the associated server name.

Execution states

GetExecutionStatus exposes an open string status:

State or category	Interpretation
`Waiting to start...` or other waiting label	Awaiting execution; continue bounded monitoring.
`Executing`	Work is active.
`Completed`	Check `ResultJson` for success or failure.
`Terminated by user`	Inspect failure/cancellation details and partial output.
`Stale`	Investigate; an empty result is not success.
Unfamiliar value	Retain the original string and investigate without rejecting the entire response.

The table is not an exhaustive enum. An unset completion timestamp or missing result does not establish success.

Parse ResultJson separately

An illustrative execution response contains a JSON string:

{
  "ExecutionId": "EXAMPLE_EXECUTION_ID",
  "Status": "Completed",
  "ResultJson": "{\"Result\":true,\"ErrorMessage\":\"\",\"ErrorNumber\":0}"
}

After parsing the outer response, decode ResultJson:

{"Result":true,"ErrorMessage":"","ErrorNumber":0}

Require boolean Result: true for reported execution success. If it is false, missing or malformed, keep the evidence and follow monitoring and recovery. Then verify actual output as required by your workflow.

History uses a different representation: GetScheduleHistory can contain string results "true", "false" or null. The string "false" is nonempty; ordinary string truthiness is incorrect.

Error numbers

Number	Meaning and action
`1041226`	Execution cleanup timeout; check activity and any delivered output before retrying.
`-102562911`	User cancellation; inspect partial output because cancellation does not reverse delivery.

These are specific outcomes, not a complete catalogue. A cleanup failure can have status Completed with Result: false.

Timeouts and retention

Window	Meaning
Client request timeout	How long your client waits for one HTTP response.
Client polling deadline	Your application’s monitoring policy; does not stop server work.
Execution cleanup timeout	Default 36000 seconds, or ten hours; configuration can differ.
Completed queue selection	Completion age under 120000 seconds, or 33 hours 20 minutes.
Failed-history selection	Calendar-day difference at most one day, not a rolling 24-hour period.

The timeout message can mention ten hours even when configuration differs. Queue selection is not a durable-retention guarantee or exact deletion schedule. Keep external records when needed.

Capacity and other limits

GetNumberOfFreeThreads reports current-server capacity in Result. The default is four, subject to configuration; values are clamped at zero. The result is a snapshot rather than a reservation.

Schedule concurrency, rendering processes and data-driver threads are separate controls. No unspecified maximum should be treated as unlimited Tableau throughput, payload size or output volume. Test representative workloads and use operation-specific constraints.

Recommended client handling

Inspect HTTP status and the selected response type.
Preserve the returned identifier immediately.
Monitor an existing run with bounded polling.
Parse nested result data and use the correct result type.
Verify content and delivery.
Check uncertain outcomes before repeating state-changing work, including state-changing GETs.

Use Troubleshoot API Integrations for symptom-specific checks.