CI/CD

Your deployment must use a contract published in its recuut environment. Automate the contract, generated-code, and application-build checks, and run them with one environment key at a time. The paid test and promotion stay manual; Go live covers them.

Keep deployment values separate

Configure these values in each deployment environment:

The snapshot check below applies to every integration. Set RECUUT_REVISION_KEY in CI even when the application uses pulled contracts. Pulled-contract applications also run the generated-code check.

Check the published contract

Choose the example that matches your application. Both call GET /merchant/v1/contracts?include_resource_key=true, require the configured revision to exist, and print that revision's stable JSON for review.

#!/usr/bin/env bashset -euo pipefail: "${RECUUT_API_URL:?Set RECUUT_API_URL for this environment}": "${RECUUT_API_KEY:?Set RECUUT_API_KEY for this environment}": "${RECUUT_REVISION_KEY:?Set RECUUT_REVISION_KEY for this environment}"contracts="$(  curl --fail-with-body --silent --show-error --get \    --max-time 30 \    --url "${RECUUT_API_URL%/}/merchant/v1/contracts" \    --data-urlencode "include_resource_key=true" \    --header "Authorization: Bearer $RECUUT_API_KEY")"if ! contract="$(  printf '%s\n' "$contracts" | jq --exit-status --sort-keys \    --arg revision_key "$RECUUT_REVISION_KEY" \    '.components.schemas[$revision_key]')"; then  echo "Published revision $RECUUT_REVISION_KEY was not found in this environment." >&2  exit 1fiprintf '%s\n' "$contract"

Create a snapshot directory with mkdir -p contracts. Save the sorted output as a reviewed snapshot for that environment, such as contracts/test.json or contracts/live.json. For example, run bash check_contract.sh > contracts/test.json, review the file, and commit it. The Python example produces the same sorted JSON.

In CI, run bash check_contract.sh > /tmp/recuut-contract.json && diff -u contracts/test.json /tmp/recuut-contract.json. Replace the first command with python check_contract.py for the Python path. A missing revision or changed reporting contract then fails the job.

The scripts also fail when the key is invalid or the configured revision is absent. An empty workspace or a key for the wrong workspace cannot pass just because the API returned valid JSON. Review x-recuut-resource-key and x-recuut-revision-key in each snapshot to confirm that test and live represent the intended product contract.

Run the check with each key: the same revision key can resolve to separate contracts, so test and live need their own reviewed snapshots.

The snapshot proves the published reporting contract and revision identity. It does not contain the Price or access setting, so it cannot prove that the revision is payable.

Check generated Python contracts

For Python generated contracts, also run recuut pull-contracts --check against the key used to generate the committed package:

recuut pull-contracts --check

The generated package uses the Resource key and public revision key, without embedding the environment-specific Resource ID. A promoted revision with the same contract can use the same generated Python names in test and live, and run the same application artifact. pull-contracts --check compares every published revision visible to its key, so a package generated from test may fail that check with a live key when the catalogs differ. For live, use the selected-revision snapshot check above.

Build the application artifact

Build the application artifact from the checked commit, keeping the API key out of the artifact. Inject the API key through the target deployment environment. Direct HTTP and raw-revision applications also need RECUUT_REVISION_KEY; pulled contracts already bind the revision. Deploy the same artifact to test and live.

For API errors, retry limits, and Retry-After, use Errors and retries. For the environment boundary, read Test and live environments.