> For the complete documentation index, see [llms.txt](https://docs.contextual.io/documentation-and-resources/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.contextual.io/documentation-and-resources/components-and-data/flows/node-reference/stream/sink-collect.md). # Sink Collect Closes a source stream and collects its items into a single message. A source stream turns one message into many, each carrying a single item. **Sink Collect** does the reverse: it waits for every item in the stream to arrive, gathers them into an array, and emits one message containing that array. Use a **Sink Collect** node in your Flow wherever a stream needs to become a single result again — before returning an HTTP response, before writing a summary record, or before any node that expects one message rather than many. See *Choosing between Source From, Loop, and Split/Join* on the *Source From* page for how streams relate to other iteration approaches in a Flow. Sink Collect is the closing half of a pair. It is used with any node that opens a source stream — a *Source From* node, or a node running in Source mode such as a *Query Object* node with **Unfold all pages to source** enabled. A node that opens a stream without reaching a Sink Collect is reported as a lint error in the editor. To configure a **Sink Collect** node in the *Flow Editor*, drag it from the **Stream** group in the Palette to the Workspace canvas, then double-click the node to open and configure its behavior. ## Properties * **Name** — optional display name for the node in the editor. By default the node shows a label of "Sink Collect"; the value you provide here replaces it, making your flow easier to read. * **Input** — the property on each incoming stream message that holds the item to collect. This is a typed input and defaults to msg.payload. * **Output** — where the collected array is written on the outgoing message. This is a typed input and defaults to msg.payload. Because **Input** and **Output** are set independently, a stream can be read from one property and the result written to another, leaving the original property untouched. ## Output shape Sink Collect always emits an array, in the order the items arrived. This holds even when the stream carries a single item. A one-item stream produces a one-element array, not the bare value. Downstream nodes can therefore treat the output uniformly, without checking whether the stream carried one item or many. The node emits exactly one message per stream. Nodes placed after it run once, not once per item. ## Example Continuing the /report endpoint from the *Source From* page, a weather application returns all of its stored readings in a single response: ``` [GET] /report → Query Objects → Source From → Sink Collect → HTTP Response ``` Ten records enter the stream through Source From, each travelling as its own message with one reading at msg.payload. Sink Collect gathers them and writes the array back to msg.payload: ```json [ { "temperature": 12, "stationId": "Dallas", "id": "jbKBEsasrH3Tjqy6oXeWbA", "datetime": "2026-08-05T17:02:00.850Z", "_metaData": {} }, { "temperature": 13, "stationId": "Irving", "id": "oQsSt3BfTSAwRcAXpdBmNt", "datetime": "2026-08-05T17:02:08.808Z", "_metaData": {} } ] ``` A Log node placed before Sink Collect shows ten separate entries. The same Log node placed after it shows a single entry containing an array of ten. That difference is the clearest way to confirm the stream opened and closed correctly. The HTTP Response node at the end of the chain receives one message, so the caller gets one JSON array. Without Sink Collect there would be ten messages arriving at a node that can only respond once. ## Collecting a stream from any source Sink Collect does not need to be paired with a Source From node specifically. It closes a stream regardless of which node opened it. Replacing Query Objects and Source From with a single Query Objects node in Source mode produces the same result: ``` [GET] /report2 → [Source] Query Objects → Sink Collect → HTTP Response ``` With **Unfold all pages to source** enabled, the Query Objects node emits its records as a stream directly — its editor label changes to \[Source] Query Objects — and Sink Collect gathers them into the same ten-element array. A Log node placed before Sink Collect shows ten entries; one placed after shows a single entry containing all ten. ## Reshaping items before collecting Any node placed between the stream source and Sink Collect runs once per item, so per-item work belongs there rather than after the collection point. In the example above, each record carries a \_metaData property that is larger than the weather data itself. Reducing each record to the fields the caller needs — before Sink Collect, while the items are still separate — keeps the collected array small, and is simpler than transforming an array of ten afterwards. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.contextual.io/documentation-and-resources/components-and-data/flows/node-reference/stream/sink-collect.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.