Three calls is the whole integration.
PUT /sessions/ci-42 with the scenario you want. Run your suite with x-flowmock-session: ci-42. DELETE /sessions/ci-42 when it's done. No SDK to install, no test-framework plugin to maintain.
In-product visual
CI & API
Set scenarios, toggle mocks, and pull logs from CI with a plain REST API and a bearer token.
"We have an E2E test for the declined-card path."
"It's skipped. We could never get staging into that state reliably."
Three curl calls — plus a GitHub Actions job sketch.
PUT /sessions/ci-42 with the scenario you want. Run your suite with x-flowmock-session: ci-42. DELETE /sessions/ci-42 when it's done. No SDK to install, no test-framework plugin to maintain.
In-product visual
Parallel jobs each get their own key and their own override scope. Ten pipelines can test ten contradictory states against one staging environment at the same time.
In-product visual
GET /scenarios?project=…&environment=… returns the scenarios your team has built, so the states QA saves by hand on Tuesday are available to the suite by Wednesday — without anyone editing a fixture file.
In-product visual
Fetch that session's request log from the Logs API and attach it to the failure. The "what did the API actually return during the failing run" question gets answered in the CI output, not in a Slack thread the next morning.
In-product visual
- name: Activate scenario
run: |
curl -X PUT "$FLOWMOCK_API/sessions/ci-$GITHUB_RUN_ID" \
-H "Authorization: Bearer $FLOWMOCK_TOKEN" \
-H "Content-Type: application/json" \
-d '{"project":"checkout","environment":"staging","scenario":"scn_paymentDeclined"}'
- name: Run e2e
env:
API_BASE: https://p.flowmock.dev/your-slot
FLOWMOCK_SESSION: ci-${{ github.run_id }}
run: npm run test:e2e
- name: Teardown
if: always()
run: curl -X DELETE "$FLOWMOCK_API/sessions/ci-$GITHUB_RUN_ID" -H "Authorization: Bearer $FLOWMOCK_TOKEN"Free plan, no card, two-minute setup.