Workflow guide

Monitor Telegram channels for new posts and text edits

Document in English

Use a recurring bounded scan when a public Telegram channel should feed a digest, spreadsheet or search index. This is batch monitoring of an observed window, not a continuous stream or a deletion detector.

1. Choose a separate baseline for each watch

Keep a unique baselineKey for each channel/filter configuration. Run writers to the same baseline sequentially. The baseline lives in your Apify account; do not share credentials or sessions to reproduce this input.

{
  "mode": "monitor",
  "monitorOutput": "changes",
  "channels": ["durov"],
  "maxPosts": 50,
  "baselineKey": "example-durov-digest",
  "messagePreview": true,
  "maxChargeUsd": 0.02
}
Download JSON

2. Understand the first and subsequent runs

The first reliable scan establishes its baseline and returns the initial message window. Later scans with monitorOutput: "changes" omit unchanged message rows. Channel context remains. New and text-edited messages can be upserted by canonicalId.

Changed channels emit a summary containing addedMessageIds, updatedMessageIds, changedChannelFields and a run-scoped eventId. Title, description, badge and linked-discussion edits are semantic changes. Subscriber/view/reaction movements and posts merely leaving the window do not create paid change events.

3. Save a Task and choose one scheduler

Test the input manually, save it as an Apify Task, then create an Apify Schedule at a frequency appropriate for the channel. Alternatively, let your existing automation platform trigger it. Do not schedule both systems against the same baseline at overlapping times.

A finite maxPosts window can miss posts between widely spaced scans on a busy channel. Changing target/filter settings resets the baseline. Switching only monitorOutput does not reset it. Inspect partial coverage, rate-limit and baseline warnings.

Connect a digest to n8n or Google Sheets

  1. Use your automation platform's Apify connector or HTTP request node to start this Actor with the same JSON.
  2. Store an Apify token only in the workflow's credential store, never in an input example or a URL query string.
  3. Retain the returned run ID, wait for that run to finish and read its dataset. Do not blindly retry an uncertain run-start POST.
  4. Filter recordType === "message" for content rows. Upsert by canonicalId and compare textHash; deduplicate summary notifications by eventId.
  5. Send the selected fields to your spreadsheet or explicitly chosen AI service. The Actor itself does not call an LLM.

These are wiring instructions, not an installed integration or a published n8n template. Start with a small bounded run before connecting a production workflow.

Budget the startup and summaries too

An unchanged scan has zero custom-event charges but still has $0.00005 startup. One newly observed billable post in one changed channel is $0.00030 + $0.001 + $0.00005 = $0.00135. A text-only edit has no new message charge, but its channel summary is billable. The first baseline is not a free backfill.

maxChargeUsd limits custom events; set a platform run limit separately. The current Apify Pricing tab is authoritative. For a simple initial export, see the JSON/CSV guide.