Environments and testing

Dry run versus separate environment

dryRun=true is a request mode on supported write operations. It is not a sandbox and does not use a separate database.

Behavior	Normal write	`dryRun=true`
Uses production endpoint	Yes	Yes
Requires valid API key	Yes	Yes
Enforces current key scope	Yes	Yes
Reads current resource state	Yes	Yes
Runs documented validation	Yes	Yes
Persists the documented mutation	Yes	No
Triggers documented notifications or email	As documented	No
Reserves state for a later write	No	No

Safe test strategy

Use a dedicated key

Create a key with the minimum company and division scope required for development or acceptance testing.

Use agreed test records

Coordinate test employees, orders, incidents, divisions, and payroll periods with the responsible customer administrators.

Validate writes first

Use dryRun=true on supported operations and inspect the projected resource and error behavior.

Apply a controlled write

Perform one real request in the agreed scope and verify all persistence and side effects.

Test recovery

Exercise timeouts, 409, 422, 429, and credential deactivation before enabling automation.

What health does and does not prove

GET /health proves that the public API is reachable and can return its health response. It does not prove:

API-key validity

tenant or division scope

access to a specific resource

availability of a downstream document file

correctness of a write payload

Use at least one protected read and one supported dry run for an end-to-end integration check.

Do not use an undocumented internal host as a fallback. A client should fail safely if the production base URL is unavailable.

Dry run versus separate environment