CI Event Validation
Validate SaaSFunnels event payload examples in CI so instrumentation drift fails before deploy.
Use CI event validation when your application keeps example payloads, contract fixtures, or event builder tests in the repository.
Validate a fixture
Run the CLI with --json so CI can parse the output:
saasfunnels events validate ./saasfunnels-event.json --source direct --jsonThe command exits non-zero for validation errors. Warnings, including a missing stable idempotency key, appear in the JSON result but do not fail the command by default. Review them or add a separate CI policy if your events must have retry-stable IDs.
Suggested workflow
- Keep one or more sanitized event fixtures in the repository.
- Run
saasfunnels events validatefor each fixture. - Fail the job on validation errors such as missing account identity, unsafe fields, or invalid semantic types. Review idempotency warnings separately.
- Keep smoke-event sends out of normal CI unless the job runs in a safe staging environment.
Example:
saasfunnels events validate ./fixtures/saasfunnels/usage-limit-hit.json --source direct --json
saasfunnels events validate ./fixtures/saasfunnels/checkout-started.json --source direct --jsonWhat validation catches
- Missing account identity.
- Invalid semantic types.
- Oversized or unsafe event names.
- Token-like or email-like unsafe fields.
- Missing stable idempotency keys.
- Non-revenue-relevant payload warnings.
- Signal-family mapping hints.
Secret handling in CI
Payload validation is local and does not need a key. Do not add SAASFUNNELS_API_KEY or SAASFUNNELS_INGEST_API_KEY to validation-only jobs.
If a staging job sends a setup smoke event, scope SAASFUNNELS_INGEST_API_KEY to the staging workspace and keep the command explicit:
saasfunnels events send-test --file ./fixtures/saasfunnels/usage-limit-hit.json --jsonProvide SAASFUNNELS_INGEST_API_KEY through the CI secret store before this step.
Feature and plan accuracy
Event payload validation and catalog drift checks are separate jobs. The CLI's install, init, agent install, and setup run commands do not add a GitHub Actions workflow. A developer must add or update that workflow and configure its required secrets.
The current LeadEngine-ai/saasfunnels-cli/action sends the existing .saasfunnels/catalog.yaml manifest. It does not freshly discover features from changed source code. Ensure that the reviewed manifest is regenerated or maintained before its handoff; an unchanged manifest cannot prove that newly added gates or features were found. setup run submits discovery directly and does not write that catalog file or install continuous synchronization.
Pull-request runs compare candidate evidence without advancing the baseline. Default-branch runs advance the evidence baseline. Plan evidence is opt-in, requires reviewed source declarations and the connected integration, and still needs review in SaaSFunnels. Pin compatible CLI and Action versions. CLI 0.3.0 normalizes approved pricing evidence locally rather than uploading raw source files; older versions have a different transport and must not be assumed compatible.
A working automation needs a committed workflow, current approved inputs, the correct scoped repository secret, successful runs, and a policy for reviewing changed findings. A green upload alone is not proof of a fresh scan, correct entitlements, or complete application coverage. Static detection currently covers supported JavaScript/TypeScript patterns, not arbitrary application languages or dynamic pricing implementations.