Skip to main content
The api_call action type is for HTTP tool steps: call partner APIs, internal microservices, or other structured endpoints with payloads and validation defined in your task (and template or script). It is not “scraping HTML”; it is first-class orchestration alongside search, crawl, and scrape.
Examples use TITAN_API_URL and TITAN_TOKEN. Tab titles match other integration pages. Rust: ureq + serde_json.

When to use api_call

  • A vendor exposes REST or GraphQL you must call before or after web steps.
  • You need stable JSON from an API plus on-page signals only available via scrape.
  • You want one Titan task to represent API + web work with shared execution history and billing.
The service applies extra validation for certain api_call URL and payload combinations—expect clear 400 errors from POST /api/v1/tasks when configuration is inconsistent.

Single-action example (POST /api/v1/tasks)

Secrets (API keys, OAuth client secrets) must not appear in payload on create if your policy forbids it—use secret_payload on POST /api/v1/tasks/:id/run instead, or inject via your vault integration at run time.

Chained example (api_call → scrape)

Use an execution_plan when the API response contains URLs you must scrape next:

Trigger via executions API

Replace the UUID with a real task_id. Modular tasks load the stored workflow; you generally do not override execution_plan on this call.