Certyn connects to your pipeline in two directions, and most teams end up using both.

Direction	What it does	Start here
Pipeline → Certyn: trigger	Your pipeline asks Certyn to run a suite, waits, and gates the deploy on the result.	GitHub Actions or the CI Runs API
Pipeline → Certyn: push results	Your existing Playwright, Cypress, Jest or pytest suite reports its results into Certyn, so they sit next to the runs Certyn started.	Bring Your Test Framework

The second one is what turns Certyn into one page for the whole picture. Your suites keep running exactly as they do today; Certyn just receives the report and keeps the history per test.

Certyn does not require branch strategy changes. Place checks at your existing decision points.

Triggering a run and gating on it

Run verification

Trigger a process with certyn-one/action@v1 or POST /api/ci/runs.

Wait and gate

Wait for a terminal state and fail the pipeline when failed > 0 or blocked > 0.

Consume outputs and artifacts

Use GitHub Action outputs or CI Runs API status fields to surface run links and pass/fail counts.

Pushing your own results

Run your suite as usual

Produce a Playwright JSON report or a JUnit XML report. Almost every framework can emit one of the two.

Upload the report

POST it to /api/ci/results with a project slug and a suite slug. A process is created for that suite on first push.

Read it in Certyn

The run appears in the same list as agent runs, with pass and fail history per test, and failures triaged as flaky or regression.

Recommended setup

1) Use two suites: smoke and regression

Smoke Suite: smoke-suite for fast critical-path checks
Regression Suite: regression-suite for broad nightly coverage

Use process slugs and aliases (smoke, regression) so suite composition stays configurable in Certyn.

2) Keep strict gates at decision points

Decision point	What to run	Gate rule
Pull request merge	`smoke`	fail if `failed > 0` or `blocked > 0`
Deploy/promotion	`smoke`	fail if `failed > 0` or `blocked > 0`
Nightly quality sweep	`regression`	fail run and alert owners

3) Keep deploy traceability with environment version

After deploy, update environment version (commit SHA, image tag, or release version) for auditability and trigger tracking.

See: Scheduling & Automation

Authentication

Create an API key from Settings -> API Keys.

Recommended CI scopes:

ci:trigger to start a run
ci:status to poll it
ci:cancel to stop it
ci:results to push your own test reports in

A key only needs the scopes for the direction you use. A pipeline that only uploads Playwright reports needs ci:results and nothing else.

CI/CD Integration