Sandbox and API Explorer

Use an approved non-production environment for integration development, contract tests, demonstrations, and support reproduction. Create only synthetic test records; never copy production Volunteer, organization, Program, Mission, registration, attendance, hours, credential, or webhook data into a sandbox.

Start safely

1. Obtain a least-privilege sandbox credential with the intended organization and Program scope.
2. Store the sandbox base URL and credential in a shell environment or secret manager, never in source, browser code, tickets, or logs.
3. Browse the OpenAPI Reference before calling an endpoint. It is the published API explorer and shows the supported request, response, authentication, error, and version contract.
4. Use the read-only health endpoint for the first connectivity check:

curl --fail --silent --show-error "$AIDORBIT_API_BASE/api/health"

Example authenticated read

After the integration owner confirms scope, this read uses no production data:

curl --fail --silent --show-error \
  --header "Authorization: Bearer $AIDORBIT_API_TOKEN" \
  "$AIDORBIT_API_BASE/api/v1/webhooks/events"

For mutations, use synthetic sandbox records and a unique Idempotency-Key. Retain the key only to retry the exact same request. On 429, wait for Retry-After before retrying with bounded exponential backoff and jitter. Record safe error codes and X-Request-Id, but never credentials or sensitive payloads.

Build only against /api/v1 routes. Review the OpenAPI diff and version guidance before promoting a sandbox-tested integration.

See also

• Integrations
• OpenAPI Reference