Plugs into what already runs in your environment.
SQACE does not replace your pipeline. It sits next to it, as an independent verification authority. To do that, it reads your sources and plugs into your existing CI/CD over REST. This page states the current state, clearly separated from what is not yet included. Technical teams should know where they stand, without reading between the lines.
What SQACE reads from.
Databases
Over JDBC
Named and in production: Oracle, Microsoft SQL Server, PostgreSQL. Any JDBC-reachable database can be connected, you bring the matching JDBC driver. SQACE reads from the source with read-only access.
Files
CSV, JSON, XML, fixed-length
Flat and structured file formats as a source for the expected/actual comparison, for example exports, interface files and extracts.
What SQACE connects to.
Web services
REST for CI/CD
Trigger verification runs over REST and pull results back. That is how you plug SQACE into Jenkins, GitLab CI, Azure DevOps or Camunda.
Test management
Jira and Xray
Link verifications and results to your test management in Jira and Xray, instead of documenting in parallel.
Driven from your pipeline, not just by clicking.
SQACE is driven over a REST API: trigger a run, poll the status, pull the verdict. That turns verification into a gate in your existing pipeline. The examples are illustrative and show the shape of the calls, not a published specification.
# 1) Trigger a run for a test suite, read the run id from the response
RUN=$(curl -sS -X POST https://sqace.example/api/v1/runs \
-H "Authorization: Bearer $SQACE_TOKEN" \
-H "Content-Type: application/json" \
-d '{"suite":"kest-release","params":{"asOf":"2026-06-30"}}' \
| jq -r '.id')
# 2) Poll the status until the run is finished (PASSED or FAILED)
until curl -sS https://sqace.example/api/v1/runs/$RUN \
-H "Authorization: Bearer $SQACE_TOKEN" \
| jq -e '.status | test("PASSED|FAILED")' >/dev/null; do sleep 5; done
# 3) Fail the build on a deviation (exit code from the verdict)
curl -sS https://sqace.example/api/v1/runs/$RUN \
-H "Authorization: Bearer $SQACE_TOKEN" \
| jq -e '.status == "PASSED"'verify-data:
stage: test
image: curlimages/curl:latest
variables:
SQACE_TOKEN: $SQACE_TOKEN # stored as a masked CI variable
script:
- apk add --no-cache jq
- ./scripts/sqace-run.sh kest-release # the script above
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"# Post the test report back to Xray automatically (run result per test case)
curl -sS -X POST https://sqace.example/api/v1/runs/$RUN/xray-export -H "Authorization: Bearer $SQACE_TOKEN"The verdict lands as a test report on the linked test case in Jira and Xray. You do not document in parallel, the result sits where your test is already managed.
The REST API is documented and viewable in the demo and in the technical review. We deliberately do not link a public specification here: we walk through the exact endpoints and fields against your setup during the review.
Available today and roadmap.
Silence and overclaiming both hurt. So here is the current state and the roadmap side by side, not blended together.
Available today
In production use.
- Databases over JDBC: Oracle, Microsoft SQL Server, PostgreSQL. Any JDBC-reachable database can be connected (bring the JDBC driver)
- Files: CSV, JSON, XML, fixed-length
- Control over REST for CI/CD (Jenkins, GitLab CI, Azure DevOps, Camunda)
- Test management: Jira and Xray
Roadmap, not today
A direction, not a current capability.
- Native connectors for modern-data-stack tools (such as dbt, Snowflake, Airflow) are not included today
- Connectors like these are a direction, not a current capability. If you need a specific source, talk to us.
Connecting does not mean your data leaves the building.
SQACE connects with read-only access to your sources and works in a protected data space, on premises or in an EU cloud. A permission concept, audit trail, versioning and automatic deletion are part of that. For how the data flow looks in detail, and which regulatory requirements each capability serves, see the Security and architecture page.
On connecting and operating SQACE.
Not as a native connector today. SQACE reads databases over JDBC and files as CSV, JSON, XML and fixed-length, and it plugs into your CI/CD via REST. Native connectors for tools like these are on the roadmap, not the current state.
Oracle, Microsoft SQL Server and PostgreSQL are named and in production. Beyond those, any JDBC-reachable database can be connected, as long as you bring the matching JDBC driver. Ask us about your specific database.
SQACE is driven over REST. That lets you trigger verification runs from Jenkins, GitLab CI, Azure DevOps or Camunda and pull results back. Test cases can be linked through Jira and Xray.
On premises or in an EU cloud, in a protected data space, with read-only access to your sources. The details are on the Security and architecture page.
Does SQACE fit your stack?
In a demo we connect SQACE to one of your sources and show the verification run over REST. For the technical integration, SQACE is driven over REST, for example from Jenkins, GitLab CI, Azure DevOps or Camunda.