How DataMasque's In-Flight Masking API Works

Updated 2 July 2026

Not all data exposure risks live in a database. Sensitive data turns up in API responses, support tickets, log outputs, and Slack threads in real time, with no data protection controls in place to catch it.

That's what DataMasque's in-flight masking API is for.

What Is In-Flight Masking?

DataMasque's in-flight masking API accepts a JSON payload at a dedicated REST endpoint and returns a masked version of that payload in milliseconds, using the same YAML ruleset and run secret as batch masking jobs, and runs entirely within the customer's own infrastructure.

Because the configuration format is identical to standard DataMasque rulesets, a platform engineer who has already configured masking for a database can apply the same masking definitions to per-request payloads without writing anything new. Provided that the same run secret is used, a customer identity masked in a database masking run produces the same masked output when that same identity arrives in an in-flight request.

The endpoint is self-hosted and runs inside your own infrastructure, so no sensitive data leaves your environment.

Four Use Cases for In-Flight Masking

In-flight masking addresses four specific scenarios where batch masking jobs cannot help: data moving between microservices, data arriving from external APIs, data needed for support debugging, and realistic data needed for sales demonstrations.

Microservices Testing

A backend service calls an identity service and gets back a user object with real PII in the response. Tests need that data shape, but can't store or log real records. Route the response through the in-flight masking endpoint before it lands in the test environment and no real PII ever reaches the development environment.

Third-Party API Integration

Payment, identity, and logistics APIs all return production data with sensitive information. Mask the response before it enters your development or staging environment to ensure those sensitive values never land in a database or log file your entire development team can read.

Production Support Debugging

When a customer reports a bug that only reproduces with their specific data, a support engineer can POST the relevant record to the in-flight masking endpoint and receive a synthetically identical masked version within milliseconds. That version can be shared safely in a ticket, a Slack thread, or a vendor escalation without exposing any real customer information.

Sales Demos and Proof-of-Concept Work

A sales engineer running a live demo needs realistic-looking customer records. Rather than fabricating data by hand or using the real thing, they can run a production sample through the in-flight masking endpoint in real time. The demo data looks authentic because it is derived from real data, with all sensitive values replaced.

How In-Flight Masking Works

DataMasque's in-flight masking API follows three steps: upload a YAML ruleset to receive a dedicated endpoint URL, POST a JSON payload to that URL, and receive the masked JSON in the response. The run secret and hash configuration (hash_columns/hash_sources) carry over from batch jobs, preserving entity consistency within and across sessions.

1. Upload your YAML masking ruleset and DataMasque provisions a dedicated REST endpoint URL scoped to that ruleset.
2. POST your JSON payload to that URL with an authenticated request and DataMasque applies the masking rules to every field defined in the ruleset.
3. Receive the masked response with field names, structure, and non-sensitive values preserved: sensitive fields carry realistic, irreversible substitutes.

The YAML ruleset uses the same format as database masking tasks, with one exception: masks that depend on database-specific context (such as from_column, which reads a value from another column in the same table row) are not available in the in-flight context. All other mask types work as documented.

Request flow:

Seeing In-Flight Masking in Practice

DataMasque's in-flight masking API takes a standard JSON object containing sensitive fields and returns a synthetically identical object in milliseconds, with each sensitive field replaced by a realistic, irreversible substitute. Field names, structure, and non-sensitive values are preserved exactly as received, with only the fields covered by the YAML ruleset rewritten.

Consider a customer object returned from an identity service.

Request payload (before masking):

{
 "run_secret": "s3cr3t-9b1f4a2c8e7d6f5a0b3c1d2e",
 "data": [
   {
     "customer_id": "12345",
     "first_name": "Sarah",
     "last_name": "Mitchell",
     "email": "sarah.mitchell@example.com",
     "date_of_birth": "1984-07-22",
     "account_balance": 4823.50,
     "account_status": "active"
   }
 ]
}


Response payload (after masking):

{
 "request_id": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
 "ruleset_plan": { "name": "customer-record-ab12cd", "serial": 0 },
 "encoding": "json",
 "charset": "utf-8",
 "logs": [],
 "data": [
   {
     "customer_id": "98765",
     "first_name": "Laura",
     "last_name": "Harrington",
     "email": "laura.harrington@fakemail.net",
     "date_of_birth": "1981-03-09",
     "account_balance": 5120.00,
     "account_status": "active"
   }
 ]
}


The data structure is identical. account_status is preserved because the ruleset does not mask it. Sensitive fields (first_name, last_name, email, date_of_birth, customer_id, account_balance) each receive realistic substitutes that match the format and domain of the original value: a plausible email address, a valid date, a realistic account balance. The original values cannot be recovered from the output.

Cross-Source Identity Consistency

DataMasque's in-flight masking uses the same run secret as batch masking jobs. If customer_id: 12345 was masked to 98765 in a batch database job, a subsequent in-flight request containing that same customer will produce the same masked replacement, provided both jobs share the same run secret.

This cross-source consistency matters in practice. A developer debugging an issue may look at a batch-masked copy of a database alongside an in-flight masked API payload for the same customer. If the two masking runs used different secrets, the customer would appear with different identities in each source, and any attempt to correlate or cross-reference records would produce misleading results.

With a shared run secret, both the database batch run and every in-flight request produce the same masked identity for customer_id: 12345. That consistency holds across all databases, environments, and request-by-request API calls simultaneously.

The run secret is set at job configuration time, or sent as part of a request, and is never stored by DataMasque. A platform or DevOps engineer should store it in a secrets manager and inject it as a parameter when starting a masking job or configuring an in-flight endpoint.

Masked identity consistency across batch jobs and per-request API calls means a single run secret is the only coordination a development team needs.

What In-Flight Masking Is Not

DataMasque's in-flight masking API is designed for masking JSON data in transit between services or before it enters a non-production system, not a form of dynamic data masking. Dynamic masking intercepts queries at the database layer, whereas in-flight masking replaces sensitive values in payloads before they reach any downstream system or log.

Dynamic data masking redacts sensitive values at read time, leaving the underlying production data stored in plaintext. It is a visibility control, useful for restricting what different database users can see, but it does not produce safe copies of data for development, testing, or AI fine-tuning.

DataMasque does not offer dynamic masking by design. Static, irreversible masking requires that the original sensitive value never exists in a non-production environment. Dynamic masking keeps production data in plaintext and applies redaction on top of it, which means the sensitive data is still present and could be exposed if the redaction layer is bypassed or misconfigured.

In-flight masking is part of the static masking model. A payload enters the endpoint with sensitive values; it exits with those values permanently replaced by synthetic equivalents. The original values are not stored, logged, or transmitted beyond the masking step.

Frequently Asked Questions

What is the latency of in-flight masking at scale?

DataMasque's in-flight masking returns a masked response in milliseconds for typical JSON payloads, because the masking step is a synchronous computation against the YAML ruleset with no database reads and no file I/O, so latency scales with payload size rather than record count. Payloads containing tens of fields return in under 50 milliseconds on standard hardware. For high-throughput scenarios, the in-flight endpoint supports concurrent requests, and DataMasque can be deployed with horizontal scaling on any cloud provider or on-premises environment.

What data formats does in-flight masking support?

DataMasque's in-flight masking API accepts and returns JSON as its primary wire format, with built-in support for masking sensitive content embedded inside string fields as XML (the xml mask type), nested JSON (the json mask type), and free-form text (the unstructured_text mask type, including AI-based entity detection). Standalone files and binary documents that require base64-free byte access, such as CSV/Parquet files and DOCX/PDF binaries, are handled by batch masking, using the same ruleset format.

Can I use the same YAML ruleset for both database masking and in-flight masking?

DataMasque's in-flight masking uses the same YAML ruleset format as other masking tasks, with one specific exception: masks that reference database-specific context (such as from_column, which pulls a value from a separate column in the same table row; from_unique, which needs a pre-known state-space; and secure_shuffle, which only works for a fixed list of values) are not applicable to per-request payloads and are not available in the in-flight context. All other mask types work identically: substitution from seed files, format-preserving replacement, date shifting, and hash-based deterministic masking all carry over without change. A ruleset written for a database masking job can generally be reused for in-flight masking by removing any from_column, from_unique, or secure_shuffle references.

Read the Documentation and See the Full Platform

DataMasque's in-flight masking API is documented in full in the DataMasque customer portal, including endpoint authentication, ruleset upload, request format, and response handling.

• Read the DataMasque in-flight masking documentation
• See the full DataMasque data masking platform