Troubleshoot API Integrations

Find the stage that is failing, run the relevant check and use its result to choose the next action.

Start with the first failing stage

1. Check Ping on the ATRS server.
2. Check Ping from the application host.
3. Obtain a fresh token and make a protected read.
4. Retrieve the intended schedule and check its report and family.
5. When an execution test is intended, submit once and save the execution ID.
6. Inspect the result, then open the output and check its destination.

Stop at the first failure. Repeating later steps can create unnecessary executions or deliveries.

Find your symptom

Connection problems

Call GET /api/Service/Ping without a token. The installation guide provides the exact PowerShell check. Expect JSON 1.

If it fails locally, inspect the API service’s running state, protocol and listener port. If local succeeds but remote fails, repeat with the server’s reachable hostname and inspect DNS, routing, firewall scope and proxy configuration.

For TLS errors, check certificate hostname, expiry, trust chain and binding using HTTPS setup. Resolve the certificate problem with validation enabled.

Authentication and permissions

Use /api/OAuth2/token for an API client or /api/Login/token for an ATRS user. Follow the complete authentication procedure.

Check the token field (access_token or token), expiry and one Bearer prefix. Then call IsSchedulerRunning. A boolean false is a valid protected response.

If the token is accepted but another operation is denied, check its permissions and resource access. Repeating authentication cannot grant missing permissions. Error bodies can be empty.

Request and response formatting

Compare method, complete path, query names, headers and serialized body with the selected reference. Use exact field casing and types. A JSON body is useful for nested objects, explicit nulls and empty arrays.

Some listing GET requests require a body that clients or intermediaries can discard. Use the POST single-schedule search when appropriate; do not invent POST equivalents for other operations.

Before parsing responses, inspect status, content type and body presence. Scalars and empty successful bodies are valid for some operations. Decode JSON-string fields such as ResultJson separately. See Errors, Execution States, and Limits.

Discovery problems

Follow Discover Folders and Tableau Resources. Check the selected configured account and Tableau permissions.

For projects, use empty parentId for roots or a project ID for direct children. For workbooks, use a project ID. For views, use a workbook ID. ATRS folder IDs are separate from Tableau IDs.

For keyword searches, supply explicit nonempty filters. An empty result should be interpreted using that operation’s search rules rather than as proof that no schedules exist.

Settings missing after an edit

Compare your full intended request with the saved schedule. Full updates need all destinations that should remain, including their identifiers. A read response is not a complete reusable update request.

For single-schedule rendering changes, use ClientRenderingSettings as shown in Parameters and Rendering. Check applySettings and exact field/value spelling.

Restore the previous intended definition on the controlled test copy, retrieve it independently and verify output before enabling recurrence. Follow the template workflow.

Execution problems

Retain ExecutionId and inspect GetExecutionStatus. For waiting or stale work, use the queue, current process view and capacity checks in Operations.

Completed can contain a failed ResultJson. A client timeout does not stop server execution. For missing records, partial output or an uncertain submission, follow Monitor, Recover, and Reconcile Executions before sending another run.

Wrong report or missing delivery

If execution reaches rendering, compare the selected Tableau account, view, parameter values and rendering settings with a working run in ATRS. Open the generated file and check content, orientation, clipping and expected pages.

If content is generated but missing at the destination, check destination enabled state, recipient arrays, mail configuration, sender permissions and server-side output path. The path belongs to the execution server’s environment, not the API caller’s computer.

For packages, check each member and destination. For data-driven output, verify each row’s content and recipient separately using the data-driven package guide.

Information to provide to Support

Prepare:

• Installed ATRS version and the affected server.
• Timestamp and timezone.
• Operation method/path and redacted request.
• HTTP status, content type and available response body.
• Schedule family/ID, execution ID and associated process/server where available.
• Expected result, observed output and checks already completed.

Remove passwords, client secrets, access tokens, confidential report data and sensitive recipient/connection details from shared diagnostics. Retain the original evidence securely so investigation does not erase it.