HttpMessageHandler Mocks or Sandbox Test Accounts: Testing an F# Integration Without Production Credentials

Consider an F# service that calls a third-party HTTP API, where integration tests must run in CI without touching production credentials. Two documented approaches compete: replacing the remote endpoint with a custom HttpMessageHandler behind HttpClient, or pointing the same code at a vendor sandbox using dedicated test accounts.

The handler-mock route is deterministic and offline, and Microsoft.Extensions.DependencyInjection supports swapping implementations per environment. The sandbox route exercises real serialization, authentication, and server-side validation that a hand-written handler cannot reproduce, at the cost of credential rotation, network flakiness, and possible drift between sandbox and production behavior.

Assuming .NET 8 and a standard xUnit project, the unresolved decision is which approach should gate merges, and whether the other belongs in a slower nightly tier.

• Should a stubbed HttpMessageHandler count as sufficient merge-blocking coverage when the vendor documents sandbox-only validation differences?
• Where should the boundary sit between DI-swapped fake handlers and real sandbox calls for a single integration?