Skip to main content

Documentation Index

Fetch the complete documentation index at: https://webscraping.titannet.io/docs/llms.txt

Use this file to discover all available pages before exploring further.

​
Scenario

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

​
Architecture

StepAPI call or concept
1POST /api/v1/tasks with execution_type: "scheduled"
2Monitor executions through GET /api/v1/tasks/:id/executions
3Inspect 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

PracticeWhy it matters
Keep one stable task IDPreserves historical continuity
Keep the schema stableSimplifies analytics and downstream processing
Use execution history for runtime visibilityAvoids mixing runtime and definition concerns
Use dataset exports for downstream pipelinesReduces the need to process each run manually

​
Next steps