Log inStart free

Test Data API: approved test data for code, pipelines and AI agents

Administrators approve versioned profiles once. Developers, CI/CD jobs and agents then request repeatable datasets within those bounds — and always release them.

How it fits together

How humans, CI pipelines and agents consume the same TDM serviceFive layers. Consumers: the human console, YAML and JSON profiles validated against a schema, the developer CLI and the Python and TypeScript SDKs. Automation: GitHub, GitLab, Jenkins, Azure DevOps, CircleCI and other compatible runners, QA frameworks, and AI coding and QA agents through a local MCP adapter. They all call one versioned REST and OpenAPI control plane, which authenticates, authorizes and isolates tenants, applies conditional approval or human review, idempotency, quotas, cost and audit, and enforces profile versions and certification gates. The control plane sends a signed outbound agent lease to the customer-resident data plane, which takes approved sources through discovery, subsetting, masking, synthesis, validation and certification into an approved target. Authorized tests connect to that target from the customer network, then the lease is released, expires or is cleaned up with evidence. Raw data and target credentials never transit DataNivra Cloud.Human and machine consumersHuman consoleYAML / JSON profiles(schema-validated)Developer CLIPython / TypeScriptSDKAutomationGitHub / GitLab /JenkinsAzure DevOps /CircleCI / BlacksmithQA frameworksAI coding & QA agents(MCP)Versioned REST / OpenAPI · DataNivra CloudAuthN / AuthZ /tenant isolationConditional approval/ human reviewIdempotency / quotas/ cost / auditProfile versions /certification gatesCustomer-resident data plane · Your environmentApproved sourcesDiscover, subset,mask, synthesizeValidate & certifyApproved targetYour test runAuthorized tests reachthe targetRelease / TTL /cleanup / evidenceSame API for every consumerMetadata-only requests (no rows, no credentials)Signed outbound agent leaseThe agent connects out; raw data and target credentialsnever transit SaaS.Tests run in your network
How humans, CI pipelines and agents consume the same TDM service. Five layers. Consumers: the human console, YAML and JSON profiles validated against a schema, the developer CLI and the Python and TypeScript SDKs. Automation: GitHub, GitLab, Jenkins, Azure DevOps, CircleCI and other compatible runners, QA frameworks, and AI coding and QA agents through a local MCP adapter. They all call one versioned REST and OpenAPI control plane, which authenticates, authorizes and isolates tenants, applies conditional approval or human review, idempotency, quotas, cost and audit, and enforces profile versions and certification gates. The control plane sends a signed outbound agent lease to the customer-resident data plane, which takes approved sources through discovery, subsetting, masking, synthesis, validation and certification into an approved target. Authorized tests connect to that target from the customer network, then the lease is released, expires or is cleaned up with evidence. Raw data and target credentials never transit DataNivra Cloud.
Text description
  1. Human and machine consumers: Human console → YAML / JSON profiles (schema-validated) → Developer CLI → Python / TypeScript SDK

    Connection: Same API for every consumer

  2. Automation: GitHub / GitLab / Jenkins → Azure DevOps / CircleCI / Blacksmith → QA frameworks → AI coding & QA agents (MCP)

    Connection: Metadata-only requests (no rows, no credentials)

  3. Versioned REST / OpenAPI (DataNivra Cloud): AuthN / AuthZ / tenant isolation → Conditional approval / human review → Idempotency / quotas / cost / audit → Profile versions / certification gates

    Connection: Signed outbound agent lease — The agent connects out; raw data and target credentials never transit SaaS.

  4. Customer-resident data plane (Your environment): Approved sources → Discover, subset, mask, synthesize → Validate & certify → Approved target

    Connection: Tests run in your network

  5. Your test run: Authorized tests reach the target → Release / TTL / cleanup / evidence

Examples in every format

TestDataProfile — the reviewed definition (privileged)
# yaml-language-server: $schema=../schemas/test-data-profile.schema.json
apiVersion: datanivra.io/v1alpha1
kind: TestDataProfile
metadata:
  name: healthcare-integration
  description: Masked patients with synthetic appointments for integration tests
spec:
  fulfilment: BUILD_DATASET
  build:
    business_domain: patient appointments
    pack_id: healthcare
    dataset_kind: HYBRID
    source_ids: [00000000-0000-4000-8000-000000000011]   # approved PostgreSQL source (synthetic id)
    subset:
      id: 00000000-0000-4000-8000-000000000021
      name: patients-with-appointments
      root_entity: {schema_name: clinic, table_name: patients}
      strategy: FIXED_COUNT
      fixed_count: 500                                    # relationships are preserved by closure
    masking_policy:
      policy_id: 00000000-0000-4000-8000-000000000031
      kind: MASKING
      version: 3
      checksum: 2c9f7a1e0b8d6c4f3e2a1b0c9d8e7f6a5b4c3d2e1f0a9b8c7d6e5f4a3b2c1d0e
    target_environment_id: 00000000-0000-4000-8000-000000000041   # the approved QA target
    retention_days: 1
    max_total_records: 2500
    scenarios:                                            # real healthcare-pack scenarios
      - {pack_id: healthcare, scenario_code: HC_ROUTINE_CARE, kind: NORMAL, default_count: 500, max_count: 500}
      - {pack_id: healthcare, scenario_code: HC_CHRONIC_CARE, kind: HIGH_VOLUME, default_count: 2000, max_count: 2000}
  automation:                                             # used only if automatic approval is enabled
    workload_identity_ids: [00000000-0000-4000-8000-0000000000a1]
    max_live_requests: 10
    escalate_out_of_envelope: true
  audit_tags: [HEALTHCARE_CI]

Created as a draft version and approved by a second person who confirms its checksum.

Ids, checksums, tenant names and URLs are synthetic placeholders.

Conditional automatic approval

People define and approve policies in advance. A qualifying workload identity — for example the customer’s trusted GitHub Actions workload identity for one repository — may then invoke the approved healthcare-integration profile only within a bounded envelope:

  • at most 500 patients and 2,000 appointments per request
  • masking policy version 3, pinned by checksum in the approved profile
  • only the approved QA target (no target can be named in a request)
  • a lease of at most two hours (lease profile over the certified version)

  1. AUTO_APPROVED

    Inside the envelope, the identity is named by the profile, quotas are not exceeded, and both the operator and the tenant enabled automatic approval.

    1,500 synthetic appointments, or a 1-hour lease of the certified version → provisioned, recorded as approved by the profile’s approver.

  2. PENDING_HUMAN_APPROVAL

    Inside the profile’s own bounds but outside the automation envelope — or automatic approval is switched off.

    A 3-hour lease when the envelope allows 2 hours → waits for a person who is not the requester.

  3. DENIED

    Outside the profile, an identity the profile does not name, a revoked or unpinned profile version, or a quota is exceeded.

    2,500 appointments (above the profile maximum), another repository’s identity, or any attempt to name a target → refused with reason codes; nothing is created.

Preview, off by default. Automatic approval needs the DataNivra operator’s switch and your tenant administrator’s switch; until then every workload request waits for a person. Preapproval is not carte blanche: profiles, sources, target references, masking policies, quotas, identity, revocation and certification are enforced by the server and by your agent, and no CI runner or AI model can approve its own request or widen its envelope.

The CI lifecycle

One pull request, one isolated test datasetA pull request starts a pipeline on a runner in the customer network. The job authenticates with its own short-lived identity, pins an approved profile version, and the control plane decides: approved, waiting for a person, or denied. The customer-resident agent hydrates an isolated copy of a certified version into an approved target, the tests run against it, and the job always releases it; a time-to-live cleans up after a runner that died. Value-free evidence records the run.CI pipelinePull requestAuthenticatePin profileversionRun testsRelease (always)DataNivra CloudDecision: approve /wait / denyLease with TTLEvidence & auditYour environmentIsolated copy of acertified versionApproved targetTeardown confirmedMetadata-only API callsSigned outbound agent lease
One pull request, one isolated test dataset. A pull request starts a pipeline on a runner in the customer network. The job authenticates with its own short-lived identity, pins an approved profile version, and the control plane decides: approved, waiting for a person, or denied. The customer-resident agent hydrates an isolated copy of a certified version into an approved target, the tests run against it, and the job always releases it; a time-to-live cleans up after a runner that died. Value-free evidence records the run.
Text description
  1. CI pipeline: Pull request → Authenticate → Pin profile version → Run tests → Release (always)

    Connection: Metadata-only API calls

  2. DataNivra Cloud: Decision: approve / wait / deny → Lease with TTL → Evidence & audit

    Connection: Signed outbound agent lease

  3. Your environment: Isolated copy of a certified version → Approved target → Teardown confirmed
  1. Pull request. A pipeline starts on the customer’s runner.
  2. Authenticate. The job exchanges its own short-lived CI OIDC token for a workload session (or uses a user session).
  3. Pin the profile. The manifest names an approved profile version and its checksum.
  4. Decide. The control plane checks bounds, identity, quotas and switches: approved, waiting for a person, or denied.
  5. Lease or build. The customer-resident agent hydrates an isolated copy of a certified version, or builds and certifies a new dataset.
  6. Run tests. Tests reach the approved target from the customer’s network; credentials never pass through DataNivra.
  7. Release. Always run on success, failure or cancel; TTL expiry cleans up a runner that died.
  8. Evidence. Value-free lease evidence and audit events record what happened.

Who uses it

Who uses DataNivra, and how
ConsumerValueDemonstration
Human developersRequest realistic datasets with a YAML/JSON manifest, the CLI, Python or TypeScript.Local setup: request → wait → test → release.
QA engineers / SDETsReproducible, DataNivra-certified datasets for regression, integration, performance, negative and edge-case tests.Pytest, Playwright, JUnit and Cypress examples in the example gallery.
GitHub Actions and GitLab CIAcquire approved test data for each pull or merge request and release it afterwards.Pipeline YAML in the repository; CI workload identity must be enabled first.
Jenkins, Azure DevOps, CircleCI, Blacksmith and other compatible runnersThe same standard API and CLI through thin, illustrative recipes — no vendor-specific engine.Generic runner recipe plus illustrative provider examples.
Autonomous QA agentsDiscover approved profiles, request data, poll and release through bounded tools.Local MCP adapter (Preview) with permission-denied, needs-approval and approved flows.
AI coding agentsObtain a reproducible, approved test environment to validate generated code.An agent requests a pre-approved regression profile pinned by version and checksum.
Enterprise data / TDM teamsKeep managing sources, classification, policies, subsetting, masking, certification, refresh, approvals and audit in the console.The existing TDM console walkthrough and synthetic playground.
Healthcare, banking, insurance, retail, SaaS, manufacturing and other sectorsDomain policy constraints and synthetic scenarios for automated testing.Fully synthetic industry examples; no compliance assurances are implied.

CI/CD platforms and runners

CI/CD integrations and their status
Runner or platformStatusRepository path
GitHub ActionsExamples in the repository; workload identity requires enablementexamples/integrations/github-actions
GitLab CIExamples in the repository; workload identity requires enablementexamples/integrations/gitlab-ci
JenkinsCompatible via the standard API/CLI — illustrative exampleexamples/integrations/jenkins
Azure DevOpsCompatible via the standard API/CLI — illustrative exampleexamples/integrations/azure-devops
CircleCICompatible via the standard API/CLI — illustrative exampleexamples/integrations/circleci
Generic shell (curl / CLI)Compatible via the standard API/CLI — illustrative exampleexamples/integrations/generic-shell
BlacksmithGitHub Actions-compatible runner example, illustrative; no partnershipexamples/integrations/blacksmith
Self-hosted runners and ephemeral KubernetesIllustrative examples; the runner must reach the approved targetexamples/integrations/self-hosted-runner

Status

What is available today
CapabilityStatusDetails
TDM console, agent, connectors and industry packsAvailableThe existing TDM product: discovery, subsetting, masking, synthesis, certification and provisioning.
Test-data profiles, plan, request, wait and release (REST, CLI)In repositoryImplemented and tested in the repository; not yet deployed to the hosted service.
YAML/JSON manifests (TestDataProfile, TestDataRequest)In repositorySafe parser, strict validation and canonical checksums in the CLI and both SDKs.
Python and TypeScript SDK helpersNot publishedNot yet published to PyPI or npm; install from the repository or release assets.
CI workload identity (GitHub Actions, GitLab CI OIDC)Off by defaultImplemented and tested; a deployment must enable it before any pipeline can sign in.
Automatic approval inside a human-approved envelopeOff by defaultPreview: needs the operator switch and the tenant switch; otherwise a person approves.
MCP adapter for AI agentsLocal onlyPreview: a local stdio adapter that calls the same API with your own session; no hosted MCP endpoint.

Questions and limitations

Is DataNivra still a Test Data Management system?
Yes. The console, agent, connectors, policies, certification and industry packs stay the product. The Test Data API is a second way to use the same customer-resident engine.
Does DataNivra run our tests?
No. Your QA tools and runners execute tests. DataNivra prepares and governs the data and the approved targets those tests use.
Can a pipeline or AI agent give itself access?
No. People define and approve profiles and envelopes with separation of duties; a request can only choose within an approved profile, and the server enforces it.
Do production rows or database credentials reach CI logs or DataNivra Cloud?
No. Row-level work runs in your network, targets are secret references resolved by your agent, and API responses carry metadata only.
Can any hosted runner reach our databases?
Not by default. Tests must run on a runner that can reach the approved target, such as a self-hosted or network-connected runner.
Are the SDKs on npm and PyPI?
Not yet. They are not yet published; install from the repository or release assets.

Test Data API overview · Profiles and manifests · CI workload identity · Automatic approval · CI recipes · MCP adapter · Troubleshooting