You are switching vendors, and the new API expects reference where your application sends orderId. EchoRelay can map both the request and the synchronous response, so the switch doesn't have to mean changing those fields throughout your application.
The target is the vendor address you send requests to. An outgoing mapping shapes the request; an answer mapping shapes the response your application receives.
Keep the contract your application already uses
Suppose your application sends:
{
"orderId": "order-482",
"amountPence": 1250
}
The new vendor expects:
{
"reference": "order-482",
"amount": 12.50
}
An outgoing mapping renames the id and divides the amount in pence to produce the pounds the vendor expects. You choose the precision and rounding rule, then preview the actual output. Similar-looking fields are not enough evidence that the units agree.
When the vendor replies:
{
"reference": "order-482",
"result_code": "OK"
}
an answer mapping can return your application's familiar body:
{
"orderId": "order-482",
"status": "accepted"
}
These bodies are illustrative contracts. You configure and test the mapping that connects them; EchoRelay does not infer that the vendor's OK means your application's accepted.
Check the error replies as carefully as the success
The vendor may use a different body for an invalid order or a rate limit. An answer mapping written for success alone can fail on those replies, and then your caller gets a 422 instead of the vendor's error.
Use answer variants, the mappings for the different forms a target can answer in. Choose what distinguishes those forms: the response status, a header or a body field. Give each relevant value its mapping, and choose what happens when no value matches.
For example, a vendor that returns HTTP 200 with an error code inside the body can be handled by a variant that gives your caller an error status. That is a response contract you define. Your request log shows the status your caller received. The target's delivery attempt still records what the vendor actually answered, and the delivery costs the same either way.
Passing an unfamiliar answer through and refusing it are both explicit choices. Pick the one your application can handle, rather than letting an unexpected response become accidental behaviour.
Preview both directions before switching
Prepare the change in a draft. Supply a request sample and a separate answer sample to the dry run. The answer cannot be inferred from the request: it comes from the vendor.
The dry run checks a single answer mapping against that sample; it does not pick or run answer variants. Review the config diff and add the new target's credential. Publish when the proposed contract is right, then send the vendor's success and error cases through a real test.
This applies to a synchronous target, which returns an answer on your caller's connection. Queued delivery has no inline answer to reshape. A streaming response passes through as a stream and is not answer-mapped.
Changing payload vocabulary is also only part of changing vendors. Different business rules, authentication requirements, timing or guarantees still need your review.
