API transformation

Reshape one API into another. Without an adapter service.

Your system speaks one shape and the partner’s API another. Today that gap is a service someone wrote and someone maintains. Describe the mapping once, both ways, and EchoRelay runs it, so the next field the partner renames is an edit, not a deployment.

Worked example

Your partner renames a field. Your caller keeps its format.

Your app submits a support request, but your help desk expects a nested ticket object. EchoRelay builds that object and maps the response back into your app's format. These examples use fictional APIs.

Configure one synchronous target: EchoRelay waits for your partner's response and returns the mapped body to your caller in the same request.

Turn a support request into a help desk ticket

Your caller sends to EchoRelay

{
  "title": "Cannot sign in",
  "reporterEmail": "user@example.com"
}

Your partner receives from EchoRelay

{
  "ticket": {
    "subject": "Cannot sign in",
    "requester": {
      "email": "user@example.com"
    }
  }
}

The request mapping puts title inside ticket.subject and reporterEmail inside ticket.requester.email.

See the request mapping (outgoingMapping) 
{
  "$schema": "https://schemas.echorelay.dev/transform/mapping/v1.json",
  "root": {
    "type": "object",
    "id": "request-root",
    "properties": {
      "ticket": {
        "type": "object",
        "id": "ticket",
        "properties": {
          "subject": {
            "type": "field",
            "id": "subject",
            "path": "title"
          },
          "requester": {
            "type": "object",
            "id": "requester",
            "properties": {
              "email": {
                "type": "field",
                "id": "requester-email",
                "path": "reporterEmail"
              }
            }
          }
        }
      }
    }
  }
}

Map the response back into your caller's format

Your partner returns to EchoRelay

{
  "ticket": {
    "id": "T-42",
    "state": "open"
  }
}

Your caller receives from EchoRelay

{
  "ticketId": "T-42",
  "status": "open"
}

The response mapping reads ticket.id and ticket.state and returns a flat object with ticketId and status.

See the response mapping (answerMapping) 
{
  "$schema": "https://schemas.echorelay.dev/transform/mapping/v1.json",
  "root": {
    "type": "object",
    "id": "response-root",
    "properties": {
      "ticketId": {
        "type": "field",
        "id": "ticket-id",
        "path": "ticket.id"
      },
      "status": {
        "type": "field",
        "id": "status",
        "path": "ticket.state"
      }
    }
  }
}

When your partner renames the field

If your help desk changes subject to title, you rename that property in the request mapping and publish the updated configuration. Your app keeps sending the same support request.

Send monitoring data in the units your partner expects

Your monitor reports a response time in milliseconds, but your reporting API expects seconds. The request mapping divides the value by 1,000 and renames the service field.

Your monitor sends to EchoRelay

{
  "service": "search",
  "durationMs": 1310
}

Your reporting API receives from EchoRelay

{
  "service_name": "search",
  "duration_seconds": 1.31
}

This mapping keeps two decimal places. It declares halfUp rounding: a value halfway between two results rounds away from zero.

See the monitoring request mapping (outgoingMapping) 
{
  "$schema": "https://schemas.echorelay.dev/transform/mapping/v1.json",
  "root": {
    "type": "object",
    "id": "monitoring-root",
    "properties": {
      "service_name": {
        "type": "field",
        "id": "service-name",
        "path": "service"
      },
      "duration_seconds": {
        "type": "arithmetic",
        "id": "duration-seconds",
        "op": "divide",
        "outputPrecision": 2,
        "roundingMode": "halfUp",
        "left": {
          "type": "field",
          "id": "duration-ms",
          "path": "durationMs"
        },
        "right": {
          "type": "constant",
          "id": "milliseconds-per-second",
          "value": 1000
        }
      }
    }
  }
}

Read how to configure and dry-run a mapping.

Why EchoRelay

Less to build, less to run.

Request and answer, both ways

The request is reshaped for the target, and a synchronous target’s answer is reshaped back into the shape your caller expects, on the same call.

Tried before it’s live

Dry-run a mapping against a sample, see the diff against what is live, and publish while traffic keeps flowing. Rolling back shows you the change before it applies.

Written by you or your agent

Hand an OpenAPI document or a sample payload to your agent over MCP and it writes the mapping; the editor in the dashboard is there for people.

Questions

Answered, honestly.

Do I need to write code to transform an API request?
No. A mapping is configuration, versioned with the line (your API version) it belongs to. You edit it in the dashboard or over MCP and publish it; nothing is deployed.
What happens when the partner changes their API?
You change that target’s mapping and publish it. Your callers keep sending exactly what they sent yesterday.
Can one target answer in more than one form?
Yes. If your vendor answers in more than one form, define answer variants: each form gets its own mapping, so an error body and a success body both reach your caller in the form it expects.

Connect everything. Deploy nothing.

Build an integration Mapping docs

No credit card required.