Example: scheduled monitoring workflow - Web Scraping Platform Documentation - Titan Network

Scenario

You want to monitor a product page every hour, keep a stable execution history, and export recurring results for downstream analysis.

Architecture

Recommended request flow

Step	API call or concept
1	`POST /api/v1/tasks` with `execution_type: "scheduled"`
2	Monitor executions through `GET /api/v1/tasks/:id/executions`
3	Inspect completed datasets and exports

Example task

curl -X POST "$TITAN_API_URL/api/v1/tasks" \
  -H "Authorization: Bearer $TITAN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Hourly price monitor",
    "urls": ["https://example.com/product/123"],
    "objective": "Track the current price and availability",
    "output_schema": {
      "type": "object",
      "properties": {
        "price": { "type": "string" },
        "in_stock": { "type": "boolean" },
        "checked_at": { "type": "string" }
      }
    },
    "execution_type": "scheduled",
    "schedule": "0 * * * *"
  }'

Why scheduling changes the integration model

In a scheduled workflow:

The task becomes the durable definition
Executions become the runtime history
Datasets become the user-facing accumulated output

That means downstream systems should anchor on the task identity and consume many executions over time.

Good practices for scheduled tasks

Practice	Why it matters
Keep one stable task ID	Preserves historical continuity
Keep the schema stable	Simplifies analytics and downstream processing
Use execution history for runtime visibility	Avoids mixing runtime and definition concerns
Use dataset exports for downstream pipelines	Reduces the need to process each run manually

Next steps