Store, warehouse & accounting

One order in.
Warehouse and accounting out.

Your store emits an order. The warehouse system wants one shape, the accounting system another, and each holds its own credentials. Describe both mappings once and EchoRelay delivers to both — so the next field a vendor renames costs you an edit, not a release.

Worked example

Send a parts order to your warehouse and accounting service

Your shop submits an order once. Your warehouse needs item codes and units; your accounting service expects a nested line. These examples use fictional APIs.

Your shop sends to EchoRelay

{
  "orderId": "ORD-42",
  "sku": "PART-A",
  "quantity": 2
}

Your warehouse receives

{
  "reference": "ORD-42",
  "item_code": "PART-A",
  "units": 2
}

Your accounting service receives

{
  "reference": "ORD-42",
  "line": {
    "sku": "PART-A",
    "quantity": 2
  }
}
  1. Create an endpoint with two asynchronous targets, using each service's URL and credentials.
  2. Give each target its own request mapping: rename fields for the warehouse and build the line object for accounting.
  3. Publish the configuration and send the order to your EchoRelay endpoint.

If accounting fails, its delivery can retry independently of the warehouse delivery. Keep ORD-42 as your business reference so each receiver can recognise a repeated order. Asynchronous delivery is at-least-once: your receivers must tolerate duplicates.

Configure the request mappings.

Why EchoRelay

Less to build, less to run.

One order, every system

The order arrives once and goes to each system in parallel, reshaped per target: the warehouse gets its field names, accounting gets its own, from the same inbound payload.

A vendor change stops here

When your accounting provider renames a field, you edit that target’s mapping and publish it. Your store keeps sending exactly what it sent yesterday, and nothing is redeployed.

Each system keeps its own credentials

Every target carries its own authentication, bound at creation to the host it may reach — so a warehouse key cannot be sent to your accounting vendor, by configuration or by mistake.

Questions

Answered, honestly.

Do you have a prebuilt connector for my warehouse or accounting system?
No, and that is deliberate. There is no catalogue to wait for or to outgrow: you describe the mapping for your systems once — from the dashboard, or by handing your vendor’s API documentation to an AI agent over MCP — and EchoRelay runs it. That is what makes it work for the systems a catalogue would never cover.
What happens if one of the systems is down?
That delivery is retried on its own schedule, spaced further apart each time, while the other system is unaffected — each target has its own retry budget. Anything still failing waits in a dead-letter queue you can inspect and replay once the system is back.
Can each system receive a different shape of the same order?
Yes, and that is the normal case. Each target has its own mapping, so one inbound order becomes whatever shape each system expects. Adding a third system later does not touch the first two.

Connect everything. Deploy nothing.

No credit card required.