Schedule VK Post Monitoring and Export Only New Public Posts

A recurring VK monitor has two different outputs: newly published posts and updated observations of posts already seen. Treating both as one stream leads to duplicate alerts or lost engagement history. The VK Posts Scraper provides stable public post IDs and timestamps so the downstream workflow can handle each case explicitly.

Create a bounded monitoring Task

For a daily job, request only enough recent posts to cover the longest expected publishing burst.

{
  "targets": ["brand_one", "brand_two", "industry_publication"],
  "maxPostsPerTarget": 30,
  "maxTotalPosts": 90,
  "maxPagesPerTarget": 3,
  "includeReposts": true,
  "includePinned": false
}

Save the input as an Apify Task and attach a daily or hourly schedule. Use Apify's webhook integration to notify a downstream endpoint only after a successful run. The dataset URL is preferable to embedding the full data in a webhook payload.

Separate new-post alerts from snapshots

Use (ownerId, postId) as the key. If the key is absent from the destination, insert it and emit a new-post event. If it already exists, update current counters or append a snapshot without alerting again.

def process(row, known_posts):
    key = f"{row['ownerId']}:{row['postId']}"
    snapshot = {
        "observedAt": row["scrapedAt"],
        "likes": row["likesCount"],
        "comments": row["commentsCount"],
        "reposts": row["repostsCount"],
        "views": row["viewsCount"],
    }
    if key not in known_posts:
        known_posts[key] = {"post": row, "snapshots": [snapshot]}
        return "new"
    known_posts[key]["snapshots"].append(snapshot)
    return "updated"

Keep the source URL in alerts so an analyst can review the public post. Do not forward media automatically to a public channel unless the workflow has permission to redistribute it.

Design for quiet periods and failures

A successful run with zero new rows is not necessarily an error; the target may not have posted. Alert on run failure, a known active fixture returning no extractable wall rows, or repeated target-level errors. Monitor runtime and results per target so a single invalid handle does not hide behind a healthy batch total.

Use a modest retry policy and avoid schedules that repeatedly request unchanged deep history. Periodically run a larger reconciliation window to catch posts that were published between outages, then deduplicate downstream.

Respect scope changes

Accounts can become private, rename handles, delete posts, or change content. Numeric owner IDs help preserve identity, but a monitor should record rather than evade access changes. Do not attempt to authenticate around new restrictions. Define retention and deletion policies for alerts and snapshots, especially when public posts concern individuals rather than organizations.