> ## Documentation Index
> Fetch the complete documentation index at: https://developers.jobhandy.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Environments and testing

> Understand the public production endpoint, dry-run validation, test-data responsibilities, and safe rollout practices.

The public contract documents one production base URL:

```text theme={"theme":{"light":"github-light","dark":"github-dark"}}
https://api.jobhandy.io/v1
```

Internal development or stage hosts are not part of the customer-facing contract and must not be embedded in public client configuration.

## 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

<Steps>
  <Step title="Use a dedicated key">
    Create a key with the minimum company and division scope required for development or acceptance testing.
  </Step>

  <Step title="Use agreed test records">
    Coordinate test employees, orders, incidents, divisions, and payroll periods with the responsible customer administrators.
  </Step>

  <Step title="Validate writes first">
    Use `dryRun=true` on supported operations and inspect the projected resource and error behavior.
  </Step>

  <Step title="Apply a controlled write">
    Perform one real request in the agreed scope and verify all persistence and side effects.
  </Step>

  <Step title="Test recovery">
    Exercise timeouts, `409`, `422`, `429`, and credential deactivation before enabling automation.
  </Step>
</Steps>

## 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.

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