> ## Documentation Index
> Fetch the complete documentation index at: https://docs.quackpay.com.br/llms.txt
> Use this file to discover all available pages before exploring further.

# Production checklist

> Prepare a Goldenfish integration for reliability, security, and operability.

Use this checklist before sending production traffic to the API.

## Request construction

* [ ] Use `https://api.aspaslabs.com` over HTTPS.
* [ ] Send `Content-Type: application/json` for JSON request bodies.
* [ ] Select a known `model` returned by `GET /v1/models`.
* [ ] Send exactly one of `choices` or `catalog`.
* [ ] Validate that choices are unique, non-empty, and within the model's limit.
* [ ] Keep the full request body available for debugging without storing sensitive user data unnecessarily.

## Authentication and secrets

* [ ] If using catalog endpoints, keep `gf_live_...` keys on your server.
* [ ] If using catalog endpoints, load keys from a secret manager or environment variable.
* [ ] Never put a catalog key in browser JavaScript, mobile app binaries, logs, or Git.
* [ ] Have a rotation or revocation process with Aspas Labs, since there is no self-service dashboard yet.

## Response handling

* [ ] Check the HTTP status before reading `output`.
* [ ] Validate `output.choice` against the choices your application expects.
* [ ] Define a low-confidence or human-review policy.
* [ ] Store `id`, `model`, and your own correlation data when your privacy policy allows it.
* [ ] Capture `X-Request-ID` for support and tracing.

## Retry policy

* [ ] Retry network failures only when the operation is safe to repeat.
* [ ] Treat `503` as temporary availability failure and use bounded exponential backoff.
* [ ] Treat `429` as a rate, concurrency, or quota response and honor `Retry-After` when present.
* [ ] Do not retry `400`, `401`, or `404` without changing the request or configuration.
* [ ] Add jitter so many workers do not retry at the same time.

## Rollout and monitoring

* [ ] Check model status before enabling a new model or revision.
* [ ] Monitor latency, status codes, low-confidence results, and fallback volume.
* [ ] Keep a representative evaluation set for every choice catalog.
* [ ] Compare results after changing the model, instruction, or catalog version.
* [ ] Exercise `GET /health/live` and `GET /health/ready` from your deployment checks.

<Check>
  The safest first production integration is a server-side wrapper with strict input validation, bounded retries, request-ID logging, and a human fallback for uncertain decisions.
</Check>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.