How to Aggregate Multiple REST Sources into a Weekly Report on Persistent Knowledge

Build a Spojit workflow that runs on a weekly schedule, pulls several REST endpoints in parallel, embeds the combined data into a persistent Knowledge collection, then queries that collection with AI to produce a narrative report and email it to your team.

What This Integration Does

Most teams have data scattered across several APIs: an analytics service, a billing system, a project tool, a status feed. Reading each one every week is slow, and stitching the numbers into a story takes even longer. This workflow does the gathering and the writing for you. It fetches each REST source with the HTTP connector, stores everything in a long-lived Knowledge collection, and then uses a Knowledge node in Query mode to read that collection and write a plain-language summary that lands in your inbox every Monday morning.

The run model is a weekly cron. A Schedule trigger fires on your chosen day and time, a Parallel node fans out into one branch per source so the fetches happen concurrently, and a Knowledge node in Embed mode writes the combined snapshot into a persistent collection keyed by the run date. A second Knowledge node in Query mode reads the freshly embedded data plus any earlier weeks already in the collection, and a Send Email node delivers the report. Because the collection is persistent, each weekly run adds to a growing archive rather than discarding its data, so your AI report can reference trends across weeks. Re-running the same week simply overwrites that week's document by file name, so back-fills stay idempotent.

Prerequisites

  • A workspace where you can create workflows in the Workflow Designer at miraxa.spojit.com.
  • The REST sources you want to aggregate, each reachable over HTTPS. If a source needs an API key or bearer token, have that value ready to place in the request headers.
  • A persistent Knowledge collection created ahead of time. Open the Knowledge section in the sidebar, choose New Collection, name it (for example weekly-metrics), and note that the embedding model is fixed at creation. This tutorial assumes Gemini Embedding 001.
  • The recipients for your report added to the org email allowlist under Settings → General → Email recipients, since the Send Email node only delivers to allowlisted addresses. To send from your own domain instead, add a Resend connection.

Step 1: Schedule the weekly run

Add a Trigger node and set its type to Schedule. Schedule triggers use a 5-field Unix cron expression plus an IANA timezone, so the run lands at the right local hour. For a Monday 8am report in Sydney, set the cron to 0 8 * * 1 and the timezone to Australia/Sydney. The trigger output is {{ scheduledAt }}, the timestamp of this run, which you will reuse as the document name later so each week is uniquely labelled.

Step 2: Fetch every source in parallel

Add a Parallel node connected to the trigger and give it one branch per source. In each branch, place a Connector node set to the HTTP connector in Direct mode, using the http-get tool (use http-post if a source needs a query body). Set the url field to the endpoint, and add any auth in the headers field, for example:

{
  "url": "https://analytics.example.com/v1/weekly-summary",
  "headers": {
    "Authorization": "Bearer YOUR_TOKEN",
    "Accept": "application/json"
  }
}

Direct mode is the right choice here: each call is a predictable single fetch with no AI cost. Name each branch's output variable clearly, such as analytics, billing, and projects, so you can reference {{ analytics.data }} downstream. Running the fetches concurrently keeps the workflow fast even with many sources.

Step 3: Combine the responses into one document

After the Parallel node, add a Connector node on the JSON connector in Direct mode using the merge tool to fold the branch outputs into a single object. Map the inputs to the branch results, for example {{ analytics.data }}, {{ billing.data }}, and {{ projects.data }}, and capture the result in an output variable named combined. If you prefer a clean labelled wrapper, use the set tool to build an object with named keys instead:

{
  "week": "{{ scheduledAt }}",
  "analytics": {{ analytics.data }},
  "billing": {{ billing.data }},
  "projects": {{ projects.data }}
}

The goal is one JSON payload that holds the full weekly snapshot, ready to embed.

Step 4: Embed the snapshot into the persistent collection

Add a Knowledge node in Embed mode. Set Collection to your persistent collection (weekly-metrics), not Transient, so the data is retained across runs. Set Document Type to JSON. For File Name, use the run date so each week is its own document and re-runs overwrite cleanly, for example week-{{ scheduledAt }}.json. For Document Input, the node expects a base64 reference, so first pass {{ combined }} through a Connector node on the Encoding connector using base64-encode, then feed that encoded value here. Leave Embedding Model matching the collection's model (Gemini Embedding 001). Capture the chunk count in an Output Variable named embedResult so you can confirm the data landed.

Step 5: Query the collection to write the report

Add a second Knowledge node in Query mode, pointing at the same weekly-metrics collection. In the Prompt field, ask for the narrative you want and reference this week explicitly:

Write a concise weekly executive report for the week of {{ scheduledAt }}.
Summarize the key analytics, billing, and project numbers, call out
notable changes versus prior weeks in this collection, and end with
three recommended actions. Use short paragraphs and a bulleted highlights list.

Set Result Count higher than the default of 5 (for example 12) so the query can pull this week's chunks alongside earlier weeks for trend context. Pick a synthesis Model for the writing. If you want machine-readable output for downstream steps, add a Response Schema to force structured JSON; if you only need an email body, leave it off and take the prose. Capture the answer in an Output Variable named report.

Step 6: Email the report to your team

Add a Send Email node to deliver the result from Spojit's built-in mail service. Set Recipients to your allowlisted team addresses (comma-separated), set Subject to something templated like Weekly report - {{ scheduledAt }}, and set Body to {{ report.answer }} (use the field your Query node returned). Set If sending fails to Fail the workflow so a delivery problem surfaces in the execution logs rather than passing silently. If you need to send from your own domain, swap this node for a Connector node on the Resend connector using the send-email tool instead.

Tips

  • Use the same embedding model for embed and query. The collection's model is fixed at creation, so do not try to switch it per run; mismatched models return poor matches.
  • Raise Result Count when you want stronger week-over-week comparisons, since the Query node only reasons over the chunks it retrieves. More chunks means more context but slightly higher AI cost.
  • Keep the cron in a timezone your readers think in. A trigger can hold multiple schedules, so you can add a second cron (for example a mid-week preview) on the same trigger without duplicating the workflow.
  • If one source is flaky, you can put a small HTTP retry-friendly endpoint behind a Subworkflow node and reuse it across reports, keeping each fetch branch tidy.

Common Pitfalls

  • Document Input must be base64. The Embed mode expects a base64 reference, so passing raw JSON directly fails. Always route the combined payload through base64-encode first.
  • Forgetting to use a persistent collection. If you pick Transient, the data is auto-cleaned at the end of the run and your report cannot reference earlier weeks. Choose the named collection for an archive.
  • Allowlist gaps. The Send Email node refuses recipients that are not on the org allowlist, so add every reader under Settings → General → Email recipients before going live.
  • Reusing the same file name unintentionally. Embedding two different snapshots under one file name overwrites the first. Keep the run date in the file name so each week is distinct.

Testing

Before turning the schedule on, validate end to end on a small scope. Temporarily point the Parallel branches at one or two real sources, then run the workflow with the Run button (a manual run executes the same steps and ignores the cron). Confirm the embedResult chunk count is non-zero, open the weekly-metrics collection in the Knowledge section to verify the document appears with status READY, and check that the report email arrives with sensible content. Once a single run looks right, add the remaining sources and let the Schedule trigger take over. You can ask Miraxa "Why did my last run fail?" if any step errors during testing.

Learn More

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.