external-api-integrationlisted

# External API Integration The leading word is **boundary**. Treat the provider as an independently changing system that can accept an effect while losing the response, delay or duplicate callbacks, reorder events, throttle callers, and evolve its contract. The boundary process is: `provider contract -> request identity -> bounded attempt -> outcome classification -> callback/poll -> reconcile -> prove` An HTTP client is only one part of this process. Keep the same operation identity and evidence across every stage. ## Scope and boundary ledger Match depth to the requested claim: - For a whole side-effecting flow, production-readiness claim, provider migration, replay, or recovery redesign, trace the full boundary chain. - For a scoped review, diagnosis, or correction, trace the affected stage and the dependencies that can change its verdict or safety. - For a side-effect-free operation, start with the provider contract, bounded attempt, outcome, and focused proof; add another stage only when it changes the requested claim. Respect explicit output and test limits. Expand only to close a safety-critical gap, and name that gap. Apply the final readiness gate to every stage in scope; report only evidence that supports the requested decision. For multi-stage side-effecting work, create one boundary ledger before explaining mechanisms: | Effect or sync | Provider evidence | Local invariant | Identity/checkpoint | Deadline/acceptance | Ambiguity/recovery | Inference or ga