[Feature Request]: Add "Limit to first row" option in the REST Client transform

[vitorsantos-commits]

What would you like to happen?

Current Behavior:
The REST Client transform executes a request for every single row that enters the step. While this is the intended behavior for most ETL processes, there are scenarios where a pipeline receives multiple rows but only needs to trigger a REST call once (e.g., to notify a monitoring system that the process started, or to fetch a single authentication token using the first row's context).

Requested Feature:
I would like to suggest adding a checkbox in the "General" tab of the REST Client transform named "Send only first row" (or similar).

When enabled:

The transform would process the very first row it receives.

It would execute the HTTP request for that row.

All subsequent rows would either be ignored or passed through without triggering additional API calls.

Why this is useful:

Performance: It avoids the need to use a "Sample rows" transform before every REST Client when only one call is needed.

Usability: It makes the pipeline design cleaner and more intuitive for "trigger-style" API calls.

Resource Management: Prevents accidental "API spamming" or hitting rate limits when the input stream unexpectedly contains multiple rows.

Proposed UI change:
A simple checkbox in the "General" settings of the REST Client transform.

Issue Priority

Priority: 3

Issue Component

Component: Hop Gui

[hansva]

I personally disagree with this one; this just sounds like bad workflow/pipeline design.

[vitorsantos-commits]

I understand that from a pure architectural standpoint, this might seem like a design issue. However, let me clarify the practical scenario I’m facing:

Imagine a pipeline processing 2,000 rows that requires an authentication token from 'API A' to be used in subsequent calls to 'API B' for each of those records.

Currently, if the REST Client is placed in this stream, it would hit the authentication endpoint 2,000 times—one for each row. This is highly inefficient, unnecessary, and often triggers rate-limiting (429 errors) or security flags from the API provider.

To solve this today, I have to use a 'Sample Rows' transform followed by a 'Database Join' or 'Stream Lookup' to broadcast that single token back to all 2,000 rows. This adds significant complexity and 'boilerplate' transforms to what should be a straightforward process.

By having a 'Send only first row' option, the REST Client could act as a singleton trigger within a dense data stream. It would fetch the token once using the first row's context and then allow the pipeline to propagate that value efficiently without redundant API calls.

My goal is to simplify the pipeline design for these common 'setup' or 'authentication' patterns that depend on stream data.

[hansva]

I would either split that logic into a reusable pipeline that fetches the token and puts it in a variable; this pipeline could then be reused in multiple workflows. Or I would create a second stream with a generate rows that creates a single line, and do the API call and merge it back into the main flow using a cartesian product.

You could also use a pipeline variable resolver, which gives you the power of a variable with a pipeline backing the logic to return the value.

[hansva]

Closing this as won't do