Implementation Examples
Copy the pattern that matches where Verixet sits in your system: CI gate, typed SDK call, backend proxy, or post-deploy operator smoke.
Choose the integration path
First CI gate
One workflow calls readiness, runs workflow/pre-deploy, and fails unless safe_to_deploy is true.
Proof file: examples/github-actions/first-gate.yml
TypeScript helper
firstGate posts the workflow payload and throws VerixetUnsafeDeployError for unsafe deploys.
Proof file: packages/verixet-ts/src/index.ts
Python helper
first_gate gives scripts the same safe-to-deploy assertion without third-party dependencies.
Proof file: packages/verixet-python/verixet_client.py
Backend proxy
Keep vg_ keys server-side while product code calls an internal validation route.
Proof file: examples/direct-nextjs
Operator smoke
Verify health, readiness, OpenAPI, and public pages after a deploy.
Proof file: scripts/verify-post-deploy-smoke.mjs
CI hard gate
Use this when a deploy runner can provide a structured snapshot of the release candidate. The job should fail on either a non-2xx HTTP response or safe_to_deploy not being true.
VERIXET_SMOKE_BASE_URL="$VERIXET_URL" npm run verify:post-deploy-smoke JSON=$(curl -sS -X POST "$VERIXET_URL/api/v1/workflow/pre-deploy" \ -H "Authorization: Bearer $VERIXET_API_KEY" \ -H "Idempotency-Key: first-gate-$GITHUB_SHA" \ -H "Content-Type: application/json" \ -d @verixet-gate-payload.json) echo "$JSON" | jq -e '.success == true and .data.workflow.safe_to_deploy == true'
- Use a key scoped to workflow:run, workflow:pre_deploy, or *.
- Keep the key in CI secrets, never in browser code.
- Persist request_id in logs so operators can trace the decision.
SDK hard gate
Use SDK helpers when you want the safe-to-deploy assertion inside a script instead of shelling through jq.
const gate = await client.firstGate({
change: "Release v1.2.3",
context: { github_sha: process.env.GITHUB_SHA },
project_structure: { root: ["src", "docs"] },
routes: ["/api/v1/health"],
apis: ["/api/v1/workflow/pre-deploy"],
db_schema: { tables: ["users", "api_keys"] },
idempotencyKey: `first-gate-${process.env.GITHUB_SHA}`,
});
console.log(gate.request_id, gate.data.workflow.risk_score);Backend proxy
Product applications should call Verixet from their backend. The browser calls your own internal route; the internal route adds the Verixet bearer key and idempotency key.