Log inStart free

Documentation

Test Data API overview

Approved test-data profiles that developers, CI/CD pipelines and AI agents invoke through REST, the CLI, YAML/JSON manifests and SDK helpers — with a five-minute synthetic quickstart.

What it is

DataNivra is a Test Data Management (TDM) system for humans, CI/CD pipelines, and autonomous AI agents. The console stays the place where your data team manages sources, classification, policies, subsetting, masking, certification, refresh and audit. The Test Data API is a second entry point to the same customer-resident engine: administrators approve versioned test-data profiles once, and authorized developers, pipelines and agents then invoke them to get repeatable datasets — always within the profile's bounds.

Status (stated plainly):

CapabilityStatus
Profiles, plan, request, wait, release (REST and CLI)Implemented and tested in the repository; not yet deployed to the hosted service
YAML/JSON manifestsImplemented in the CLI and both SDK helpers
Python and TypeScript SDK helpersNot yet published to PyPI or npm; install from the repository or release assets
CI workload identity (GitHub Actions, GitLab CI)Off by default; a deployment must enable it
Automatic approval inside an envelopePreview; off by default (operator switch and tenant switch)
MCP adapter for AI agentsPreview; local stdio adapter only

DataNivra does not run your tests. Your QA tools and runners execute tests; DataNivra prepares and governs the data and the approved targets those tests use.

Two resources, deliberately separate

  • A profile definition (TestDataProfile, stored as a TEST_DATA_PROFILE policy version) is privileged: it fixes sources, pinned policy versions, the target or a pool of target references, upper bounds and an optional automation envelope. A second person approves each version and confirms its checksum. See Profiles and manifests.
  • A profile invocation (TestDataRequest) is minimal: it pins a profile name, version and optionally the checksum you reviewed, and may only choose scenarios, exact counts and a TTL within the profile. It can never name a source, target, policy or envelope.

The control plane turns an invocation into the ordinary operations that already exist — a dataset request or an environment lease — so every existing check (policies, certification, separation of duties, quotas, audit) still applies.

Routes

MethodPathPermission
GET/v1/test-data/profilestest_data.request
POST/v1/test-data/plantest_data.request
POST/v1/test-data/requests (accepts Idempotency-Key)test_data.request
GET/v1/test-data/requests, /v1/test-data/requests/{test_data_request_id}test_data.request
POST/v1/test-data/requests/{test_data_request_id}/approve, /rejectdataset.approve
POST/v1/test-data/requests/{test_data_request_id}/releasetest_data.request
GET, PATCH/v1/organization/test-data-settingsorg.admin
GET, POST/v1/workload-identities, /v1/workload-identities/{workload_identity_id}, /disableorg.admin
POST/v1/auth/workload/tokenpublic (the CI token is the credential)

test_data.request is held by the Developer, QA engineer and TDM engineer roles (and the organization owner) — every one of them could already request datasets.

Five-minute synthetic quickstart

Run against a local, synthetic control plane (for example make demo-local) or a tenant where an administrator approved a profile. Everything below is synthetic.

  1. Sign in: datanivra login --base-url http://127.0.0.1:8000 --tenant demo --email owner@demo.datanivra.example.test (local dev login), or datanivra login --device --tenant <SLUG> against a hosted tenant.
  2. List what you may invoke: datanivra test-data profiles.
  3. Write a request manifest pr-regression.yaml:
apiVersion: datanivra.io/v1alpha1
kind: TestDataRequest
metadata:
  name: pr-regression
spec:
  profile:
    name: healthcare-integration
    version: 1
  purpose_ref: QA-1234
  1. Validate it locally (no network): datanivra test-data validate pr-regression.yaml — prints the kind, name and canonical checksum; exit code 28 if invalid.
  2. Dry run: datanivra test-data plan pr-regression.yaml -o json — the decision (AUTO_APPROVED, PENDING_HUMAN_APPROVAL or DENIED) with reason codes, resolved scenarios, TTL and a request_checksum reproducibility pin. Nothing is created.
  3. Request and wait: datanivra test-data request pr-regression.yaml --wait -o json > request.json — exit 0 when READY.
  4. Run your tests against the approved target from your network.
  5. Release: datanivra test-data release "$(jq -r .id request.json)" --reason-code TEST_RUN_FINISHED.

Which path fits you

You areAuthenticate withDecision you can expect
A person using the consoleYour normal sign-inThe console flows you already use
A developer or QA engineer using the CLI or an SDKA user session (datanivra login --device)Exactly your existing powers: a lease needs dataset.provision, a build follows your tenant's approval scope
A CI pipeline (GitHub Actions, GitLab CI)Its own OIDC token exchanged for a workload session (CI workload identity)Denied unless the profile's envelope names the identity; approved automatically only inside the envelope and when automatic approval is enabled; otherwise a person approves
An AI agentThe local MCP adapter using the session of the person or workload that runs itSame rules as that session; the agent can never approve or widen anything

Release, revoke and cleanup

Releasing a request ends only what it holds — see Lease vs revoke and troubleshooting.

← All documentation