Virtual APIs
One source of truth. Many governed views. A Virtual API is a governed view of an existing dataset. Instead of cloning data or building custom pipelines for each consumer, you define a declarative spec that applies redaction, tokenization, and transformations at the field level — automatically, per route.How it works
- Enroll your data source (REST API today, data lakes coming soon)
- Define your spec — object definitions, filters, and access controls
- Publish — your Virtual API is instantly available
- Monitor — observe usage and schema changes over time
Basic configuration
A Virtual API spec defines which fields to protect, organized by the API objects (route segments) they apply to:ssn and date_of_birth and anonymizes email for any request matching the customers route — such as /api/customers or /api/customers/456.
Object definitions and route matching
Each key underobjects is a named object definition that matches against URL path segments. DataHarbor matches the object name to the last (or second-to-last) segment of the request path.
| Request path | Matched object |
|---|---|
/v1/addresses | addresses |
/v1/addresses/1 | addresses |
/api/users/123 | users |
Targeting nested and array fields
Target nested fields using dot notation, and array items using[arrayName] syntax:
name, plus the name and city fields inside every item in the addresses array — all within a single object definition.
For nested objects, use dot notation:
Multiple views from one source
One enrolled API can power many governed views, each with different filter configurations:The _default object
_default is an optional catch-all that applies when no named object matches the request route:
addresses), only that object’s filters apply. When no named object matches, _default filters apply.
Spec options
| Option | Default | Description |
|---|---|---|
failOnUnmatchedObject | false | Reject requests that don’t match any defined object |
useStrictNameMatching | true | When false, match field names case-insensitively |
Versioning
Every change to a Virtual API creates a new version. You can:- View the full version history
- Compare configurations between versions
- Roll back to a previous version
- Audit which version was active at any point in time
Lifecycle
| State | Description |
|---|---|
| Active | Live and accepting requests |
| Expired | Past expiration date, no longer accepting requests |
| Inactive | Manually disabled, instant shutdown |