Standby Actor in TypeScript

What does LLM Wiki Manager do?

LLM Wiki Manager is a standby Apify Actor that exposes an HTTP endpoint for inbound Notion-style webhook payloads. It accepts JSON requests on /notion, logs a compact set of file update metadata when a file object is present, and logs the verification_token field when the payload includes one.

Because it runs as an Apify Actor, you can host it with a managed standby URL, inspect requests from the Standby tab, monitor runs, connect it to automations, and integrate it through the Apify API. If you want to test the Actor locally first, you can run it with apify run and send sample requests to the local standby server.

Why use LLM Wiki Manager?

This Actor is useful when you want a lightweight webhook receiver for wiki or knowledge-base workflows without building and hosting a separate API service. It gives you a simple place to observe incoming file update events, verify request payloads, and extend the workflow later with storage, downstream API calls, or synchronization logic.

Typical use cases include validating incoming Notion automations, auditing metadata changes for updated documents, and using Apify as a managed integration surface for internal tooling. The standby deployment model also makes it easy to expose a stable endpoint while keeping the implementation in a normal Actor codebase.

How to use LLM Wiki Manager

1. Open the Actor in Apify Console or run it locally with apify run.
2. Start the standby Actor and wait for the web server to become ready.
3. Send a POST request to the /notion endpoint with a JSON payload.
4. Include verification_token if your sender provides one and include a file object in one of the supported payload locations.
5. Check the Actor logs to confirm that the verification token and file metadata were recorded.

Input

This Actor does not require a start input schema because it is driven by HTTP requests while running in standby mode. The request schema for the standby API is described in .actor/openapi.json using Apify’s webServerSchema support.

The POST /notion endpoint accepts a JSON object. The Actor currently looks for file metadata in these locations:

• file
• data.file
• file_update.file
• event.file
• entity

Example request body:

{
  "verification_token": "secret-token",
  "data": {
    "file": {
      "id": "file-123",
      "name": "Engineering spec",
      "url": "https://www.notion.so/file-123",
      "last_edited_time": "2026-06-01T12:00:00.000Z"
    }
  }
}

Output

This Actor is an integration-style standby service and does not publish dataset items or files by default. It responds synchronously to HTTP requests and writes operational details to the Actor log.

Successful response:

{
  "ok": true
}

Error response for invalid JSON:

{
  "ok": false,
  "error": "Invalid JSON payload"
}

You can download dataset outputs in formats such as JSON, HTML, CSV, or Excel when an Actor uses datasets, but this Actor currently does not emit dataset records.

Data table

Field	Type	Description
verification_token	string	Logged when present in the incoming payload.
id	string	File identifier logged when found in the payload.
name	string	File name logged when found in the payload.
title	string	Alternate file title if supplied by the sender.
url	string	File URL logged when present.
last_edited_time	string	Last edit timestamp logged when present.

Pricing / Cost estimation

How much does it cost to run this Actor? For low-volume webhook handling, costs should usually be minimal because the Actor only processes lightweight JSON requests and logs metadata. Actual cost depends on how long the standby Actor runs, request volume, and your Apify pricing plan.

If you are testing on a small scale, Apify’s free tier may be enough. Keep runs focused and avoid unnecessary background processing if you want to minimize compute usage.

Tips or Advanced options

Use the Standby tab generated from the Actor’s OpenAPI schema to test /notion directly in Apify Console. If your sender’s payload shape is more specific than the current flexible schema, you can tighten .actor/openapi.json and the extraction logic together.

If you later want durable audit trails, extend the Actor to store normalized webhook events in a dataset or key-value store and update the output schema accordingly. That will make the results visible in the Output tab and through the Apify API.

FAQ, disclaimers, and support

This Actor is intended for receiving webhook-like JSON payloads and logging operational metadata. Make sure you only process data you are authorized to receive and store, and review any Notion or third-party platform terms that apply to your integration.

The current implementation is intentionally conservative: it logs selected metadata fields and does not attempt to mutate external systems. If your webhook payload shape differs from the documented example, you may need to adjust the schema and extraction paths.

If you want to extend the Actor, use the project Issues tab or your normal repository workflow to track changes. Customization for storage, downstream synchronization, or richer validation is straightforward from this starting point.