Skip to main content
At the highest level, the platform has three layers. The same architecture supports classic extraction (URLs plus schema) and modular tasks that combine search, crawl, scrape, and API-call actions—see Action types overview.
  • A user layer
  • A control plane
  • A worker layer

​
Platform diagram

​
Service responsibilities

LayerComponentPrimary responsibility
User layerDashboardUser-facing workflows for tasks, executions, datasets, billing, and analytics
User layerAuthSessions, JWTs, API keys, and identity
Control planeTask ServicePublic API for tasks, executions, templates, results, datasets, and media access
Control planeScheduler ServiceNode registration, work coordination, and dispatch behavior
Control planeIngestion ServiceStructured result intake and media upload lifecycle
Control planeBilling ServiceWallet state, charging, and ledger truth
Control planeAnalytics ServiceUsage reporting and aggregate metrics
Worker layerBrowser nodesStandalone Playwright and Puppeteer execution nodes
Worker layerChrome extension workersExtension-based execution workers

​
End-to-end request flow

​
Ownership boundaries

ConcernSource of truth
Identity and API keysAuth
Task definitionsTask Service
Execution lifecycleTask Service
Worker dispatch and assignmentScheduler Service
Structured output and media intakeIngestion Service
Wallet and ledger accountingBilling Service
Usage reporting and trendsAnalytics Service
These boundaries matter because they show integrators where to look first when building clients or debugging a workflow.

​
Why this structure matters

The public user model stays stable even if worker implementations change. Users continue to create tasks, run executions, and fetch results from the same public APIs while worker internals evolve behind the scenes.

​
Next steps