Skip to content

Latest commit

 

History

History
65 lines (51 loc) · 2.08 KB

File metadata and controls

65 lines (51 loc) · 2.08 KB

Integration Flow

BotV8 applications use a language SDK to create a profile-backed runtime, run approved Web API work, send approved requests through the environment, and collect sanitized evidence.

Quick Model

flowchart TD
  App[Application] --> SDK[BotV8 SDK]
  SDK --> Env[Profile-backed environment]
  Env --> Page[Web API runtime work]
  Env --> Request[Approved request through environment]
  Env --> Report[Sanitized report]
Loading

The application owns its product workflow. BotV8 owns the profile-backed runtime, cookie state, storage state, network execution, and report generation.

Runtime Sequence

sequenceDiagram
  participant App as Application
  participant SDK as BotV8 SDK
  participant Runtime as BotV8 environment

  App->>SDK: start runtime package
  App->>SDK: create environment with profile and optional proxy
  SDK->>Runtime: initialize profile-backed state
  App->>SDK: navigate or evaluate approved page logic
  SDK->>Runtime: run Web API work
  App->>SDK: request sanitized report
  Runtime-->>SDK: report summary
  SDK-->>App: result objects
Loading

Request Flow

sequenceDiagram
  participant App as Application
  participant SDK as BotV8 SDK
  participant Runtime as BotV8 environment
  participant Service as Approved endpoint

  App->>SDK: provide endpoint, method, headers, and body
  SDK->>Runtime: send request through environment
  Runtime->>Service: request with profile-backed context
  Service-->>Runtime: response
  Runtime-->>SDK: sanitized metadata and configured body mode
  SDK-->>App: response object
Loading

Use this path when a request belongs to the runtime workflow. BotV8 keeps runtime, cookie, storage, and network state together for the call.

Evidence Flow

flowchart LR
  Runtime[Runtime work] --> Summary[Sanitized summaries]
  Summary --> QA[QA review]
  Summary --> Support[Support triage]
  Summary --> Release[Release comparison]
Loading

Reports are meant for local review and release comparison. They should not contain private profiles, credentials, customer traffic, raw service responses, or reusable test internals.