Skip to main content
Back to Use cases

Request/Response Transformation & Protocol Bridging

Transform payloads, map fields, and adapt between legacy formats and modern APIs using visual workflows.

Practical use cases

Concrete ways teams use Zerq for this scenario.

  • Expose a modern REST API in front of a legacy system

    Your backend expects XML or an old schema; clients want JSON and clear field names. The workflow receives the client request, maps fields, calls the legacy backend, then transforms the response (e.g. rename fields, strip internal data) before returning. You change the mapping in the workflow when the contract evolves.

  • Serve different response shapes per partner or version

    Partner A needs v1 fields; Partner B needs v2. Use a branch on header or partner ID and return the appropriate transformed response from the same backend call. One backend, one workflow, multiple client-facing shapes.

  • Inject headers, normalize paths, or redact sensitive data

    Add auth or correlation headers before forwarding; normalize paths so clients use clean URLs; filter or redact fields in the response for certain partners. All in the workflow, with a full audit of what was sent and returned.

Outcomes

  • One gateway layer for protocol and schema adaptation; clients and backends stay decoupled.
  • Change mapping and versions in the workflow designer instead of in code.
  • Consistent audit trail for what was transformed and returned.

How Zerq helps

  • Workflow steps can call a backend and then apply logic: use a custom response node to return a transformed body; reference the upstream response and build a new JSON/body from it.
  • Conditional branches by header or path: apply different transformation logic per client, version, or partner (e.g. v1 vs v2 response shape).
  • Optional code node for complex mapping or XML/JSON conversion when visual nodes are insufficient; all still versioned and audited in the workflow.
  • API products and versions: expose v1 and v2 as separate products, each backed by workflows that return the appropriate schema.
  • Structured logging and metrics so you can see transformation errors and latency in one place.
For architects & evaluators (technical context, requirements)

Technical context

Legacy systems often expose different shapes (XML, flat JSON, custom headers) than modern clients expect. Partners may require a specific schema or version. The gateway must transform requests before they hit the backend (e.g. map client fields to backend fields, inject headers, normalize paths) and transform responses (e.g. rename fields, filter sensitive data, wrap in a standard envelope). Doing this in a central place avoids duplicating transformation logic in every consumer.

Technical requirements

  • Request transformation: modify path, headers, query, or body before forwarding to backend.
  • Response transformation: modify status, headers, or body before returning to client.
  • Support for different content types (JSON, XML if applicable) and schema versions.
  • Conditional transformation (e.g. different mapping per partner or API version).
  • Reuse and maintain transformations without redeploying the gateway binary.

Request Enterprise Demo