Reusing a Response

Some APIs return everything in one call. A warehouse queue, for example, may hold shipment headers, package lines and reason codes in a single list. Inner reads and child endpoints often need more of that same data for each record: "the load row for this shipment", "the packages on this order", "the reason code for this line".

If each of those reads sends its own request, the endpoint downloads the whole response again for every record. A run with 1,000 records can make thousands of identical calls.

Use the response from lets a read take the response an earlier read already fetched in the same run, instead of sending its own request.

When to use it

Use it when an inner read or a child endpoint's read:

• Sends the same request for every record: its URL and body don't change from record to record, and
• Narrows the rows down with its Data Selector, for example Collection[?(@.Load_Nbr == '{CD:Load}')].

The configuration validator warns about reads like this: "This read sends the same request for every record…". When the warning names an endpoint, that endpoint's read already fetches the data.

Setting it up

1. Open the inner read, or the child endpoint's read, on the Get Changes action.

2. In Use the response from, choose the endpoint whose read already returns the data. The list shows:

   • This endpoint (inner reads only)
   • The endpoints it runs under (its parent, grandparent, and so on)

   Each option shows the endpoint name, the read's title and its request path, e.g. HyTek - 0615 › Read · GET RequestWMSMessages. Once you choose one, its full request shows below the picker.

3. Keep your Data Selector; it's required. Placeholders such as {CD:Load} or {FK:SalesOrderId} are still filled in for each record. The selector now picks rows from the reused response. {SYS:ParentId} and {SYS:PrimaryId} aren't filled in inside a selector, so match the record with {PK:…}, {FK:…} or {CD:…} instead.

When a source is chosen, the read sends no request. The URL, body, paging and instruction settings are hidden and cleared, because they no longer apply. The action card shows a badge with the source's name.

What stays the same

Mapping, filters, aggregation and keys work exactly as before. The read sees the same rows it would have fetched itself. The difference is that every lookup in a run sees one snapshot of the data, even if the source system changes partway through the run.

Trimming padded values

Some systems pad values with spaces ('114605977 '). Instead of adding a trim transform to every map, switch on Trim Response Values on the read that sends the request. It's available on any read action of a JSON, XML or SQL endpoint, and on the top-level read of a file endpoint, and it also applies to webhook payloads. Each read decides for its own response, so a future-publish read has its own switch. Every text value in the response is trimmed once, as it arrives:

• Every map on that endpoint sees trimmed values.
• Reads that reuse the response see them too, marked with a Trimmed by … chip.
• Selectors can compare with ==: @.Load_Nbr == '{CD:Load}' matches once the padding is gone.

Test Request on a read with the switch on shows the trimmed response, as the run would see it. To see the raw values, turn the switch off on the read and test again.

For a single padded field, use the Trim transform instead (both sides, start only, or end only).

Rules

• Valid sources. A read can reuse the response of its own endpoint (inner reads only) or of an endpoint it runs under. It can't use a child's response; children run later.
• Polling publishers only. Reuse works on the publisher's Get Changes read and its inner reads, for JSON and XML endpoints that call an API. Both endpoints must use the same protocol. Webhook publishers and future-publish endpoints start from a single record, without the source's response, so the option isn't offered there.
• Not on connector-specific data services. Endpoints that use a connector's own data service can neither reuse a response nor be a source.
• Sources must send their own request. The source read must send its own request and must not Load Children Together. While other reads reuse an endpoint's response, its read shows how many depend on it and keeps those options locked.
• No Test Request. A read that reuses a response sends no request, so it has no Test Request. Test the source read instead.
• No silent fallback. If the source hasn't been read in the run, the read reports an error. It never falls back to sending its own request.