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.
Store, warehouse & accounting
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
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.
{
"orderId": "ORD-42",
"sku": "PART-A",
"quantity": 2
}
{
"reference": "ORD-42",
"item_code": "PART-A",
"units": 2
}
{
"reference": "ORD-42",
"line": {
"sku": "PART-A",
"quantity": 2
}
}
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.
Why EchoRelay
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.
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.
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
No credit card required.