API Versions and Compatibility
Use the latest ATRS documentation and verify the workflows your integration depends on.
These guides cover the latest version of ATRS. Find the latest release information and download ATRS from the ChristianSteven website.
Check compatibility for the operations and reporting workflows your application uses. Keep the exact installed version and tested configuration in your deployment records.
Understand the version labels
| Label | Meaning |
|---|---|
| Installed ATRS version | The software running in your environment; record it for testing and Support. |
| Documentation version | The ReadMe documentation set you are viewing. |
| OpenAPI version | The specification’s API label; OpenAPI 3.0 identifies the document format. |
| URL paths | Use the complete paths in the reference, without inventing a /v1 segment. |
For the two Postman downloads and import instructions, see Use the ATRS API with Postman.
Record your integration configuration
Keep the installed ATRS version, specification copy, application/client version, base address, authentication flow and tested workflows together. In a multi-server environment, record every participating server’s version and access to shared dependencies.
Record the ATRS version and API configuration used for each integration test.
Check each operation
Before building or regenerating a client, review:
- HTTP method, complete path and query names.
- JSON/content type and operation-specific property spelling.
- Required values, nulls, empty arrays and strings.
- Response shape and whether a successful body can be empty.
- State changes, execution mode and retry behavior.
Use /api/OAuth2/token for API clients and /api/Login/token for users. Read expiration from the returned fields as shown in Authentication.
Some GET operations carry JSON bodies. Test them through the actual client and intermediary. Use the documented POST single-schedule search where appropriate; do not invent alternatives.
Keep request and response models separate
| Representation | How to use it |
|---|---|
| Single-schedule create/update | Full intended definition, including ClientRenderingSettings and complete destination arrays. |
| Saved schedule response | Inspect configuration; it can omit settings needed for a full update. |
| Package creation | PackageName, Reports, recurrence, complete destinations and the package data-driver model. |
| Exported definition | A compatible output from a supported transfer process, not a GET response or authoring request. |
For single schedules, ClientRenderingSettings drives rendering writes. Internal RenderingSettings uses different field names and numeric values. Follow Parameters and Rendering rather than treating the two objects as interchangeable.
Preserve identifier casing by operation: UniqueId, uniqueid, Id and id can appear in different models or queries. Additional object properties do not automatically establish writable features.
Check response handling
Use the selected response type: number, boolean, string, array, object or empty body. Decode populated ResultJson separately and preserve unfamiliar status values for investigation. A completed execution can contain a failed result.
Read a changed schedule independently to verify it. An echoed request is not independent proof of persistence.
Test when ATRS or your client changes
In a controlled environment:
- Check local and remote connectivity.
- Obtain and renew the authentication method your application uses.
- Discover the approved reporting resources.
- Read and deliberately edit a test schedule using its full intended definition.
- Submit one execution, retain its ID and monitor the result.
- Open the report and verify content and delivery.
- Exercise your recovery path for a lost response or polling interruption.
Include package creation, data-driven output and collaboration in your tests where your integration uses them. Follow Create and Manage Report Packages and Create a Data-Driven Tableau Package for the package workflows.
Before production changes, follow the applicable product update instructions and backup/recovery plan. Afterward, repeat your tested workflows and record the installed version and results.
Investigate a compatibility problem
Compare the failing operation with the saved specification and previous working request. Record the exact installed version, method/path, timestamp, redacted request, response and observed output.
Use Troubleshoot API Integrations for diagnosis and Monitor, Recover, and Reconcile Executions for uncertain executions.
Updated about 7 hours ago