# HTTP, runtime, and frameworks
> **TARGET architecture — implementation pending.** Runtime and transport
> details remain to be selected and tested; these are the required boundaries.
## Default path
Built-in remote adapters use a secure default HTTP transport. A normal user
configures credentials, product settings, timeout, and policy without choosing
an HTTP client. Defaults must include TLS verification, bounded response sizes,
connection reuse, a total operation timeout, and redacted diagnostics.
`HttpTransport` is available only on the
advanced path for corporate proxies, deterministic tests, tracing integration,
custom TLS policy, and unusual runtime environments. It deals in constrained
SDK request/response types rather than exposing a chosen HTTP library's public
types, protecting core API stability.
The complete request/response SPI, one-send rule, custom-transport trust
boundary, and illustrative proxy construction are defined in the authoritative
[HTTP transport boundary](http-transport.md).
Transport injection must not bypass adapter validation or permit secret/token
logging by default. Cancellation and the timeout budget flow from `Captcha`
through the adapter to the transport. Transport, safe internal retries,
response parsing, and verdict production consume the same `.timeout(Duration)`
budget. `AttemptOptions::timeout` may shorten one call; absolute deadlines remain
deferred. Cancellation and retry semantics are defined in
[Attempts and safe retries](attempts-and-retries.md).
## Endpoint overrides
Changing a provider verification endpoint can exfiltrate provider credentials
and `CaptchaToken`. Endpoint override is therefore explicitly dangerous,
test-only, and feature-gated. It is absent from ordinary production builders,
requires conspicuous naming/documentation, accepts only validated HTTPS unless
a test-only local exception applies, and remains redacted from diagnostics.
## Framework boundary
Core is server-side and framework-agnostic. It accepts normalized values such
as `CaptchaToken` and `IpAddr`; it does not know about HTTP headers, cookies,
forms, middleware, extractors, responses, or sessions.
A future Axum integration is a companion crate or optional module depending on
core. It may extract a token, derive a trustworthy remote IP under an explicit
proxy policy, invoke `Captcha::assess`, and map errors/denials into application
responses. The dependency direction is always framework integration → core.
Similar integrations can be built for Actix Web, Rocket, or Tower without
changing the verification model.
No server integration renders frontend widgets. Provider JavaScript and widget
modes remain application/frontend concerns.