Quick start
- Create an authorized workspace API key in Settings → API Keys.
- Store the key in your CI secret manager, not source code.
- Check both the pass verdict and a saved scan ID before accepting the gate.
Run a CI scan
POST /api/ci/scan accepts a Bearer API key and returns passed, score, failures, and scanId. Browser scan/history routes use application sessions; the old POST /api/scans example was not a valid scan-creation contract.
Set REGLAYER_URL to your actual deployment origin. This example requires curl and jq, disables stored policies explicitly, and checks persistence as well as the verdict. Configure your shell or CI to fail on nonzero exit status. Network errors, malformed responses, and a null scanId must fail the gate.
Use only public URLs you are authorized to test. Validate this integration in a controlled environment before relying on it as a release gate. Supported options and deployed behavior may vary; do not infer a daily plan quota or an unimplemented threshold from this example.
# Run with Bash; curl and jq are required.
set -euo pipefail
# Set REGLAYER_URL to your deployment URL and REGLAYER_API_KEY to a CI secret.
# Only scan sites you own or have permission to test.
curl --fail-with-body --silent --show-error --max-time 100 \
-X POST "${REGLAYER_URL}/api/ci/scan" \
-H "Authorization: Bearer ${REGLAYER_API_KEY}" \
-H "Content-Type: application/json" \
-d '{"url":"https://example.com","failOnScore":80,"failOnCritical":0,"usePolicies":false}' \
| jq -e '.passed == true and .scanId != null'Credentials and authentication
API keys identify a workspace and must be treated as secrets. Do not put them in client code or a scan URL. Revoke exposed keys. Session-only endpoints and API-key endpoints have separate authentication checks.
Do not automatically retry non-idempotent scan submissions after an ambiguous network failure; check for a saved result first. Respect actual error responses and rate-limit headers rather than a fixed, undocumented requests-per-minute promise.
Verify webhook delivery
Configure enabled webhook destinations and selected events on Webhooks. Actual event emission depends on the workflow; registering an event name does not prove every route emits it.
When a webhook secret is configured, X-RegLayer-Signature uses sha256= followed by an HMAC-SHA256 of the raw request body. Verify against that raw body and reject missing or invalid signatures according to your receiver's policy. Without a configured secret, the sender does not provide that signature.
Delivery retries can repeat a message. Use X-RegLayer-Delivery for receiver deduplication and review failed delivery records. A successful settings save does not confirm that the destination accepted a message.