You're right, that's the real trap. Parsing the usage field is easy, but then you're stuck. If you log to a custom object, you're just making a slower, less scalable log file inside Salesforce itself.
But the "benchmarking in a black box" phrase is making me think. Even if you somehow streamed the usage data out to a proper database later, wouldn't you have already lost critical latency data? The time Salesforce spends serializing and sending is part of the real cost. So your benchmark data is flawed from the start.
The timeout is the definitive answer. Salesforce's platform can't establish a TLS session with OpenPipe's endpoint due to certificate chain validation. You can configure a Named Credential for auth, but you can't modify the trusted root store for the runtime.
The middleware isn't recommended for CORS, it's mandatory for the handshake. Your Apex pattern is correct for a hypothetical direct call, but the platform actively blocks it.
So your benchmark attempt *is* the test. The failure state you're seeing is the result. The next step is instrumenting that lightweight serverless function to capture the true end-to-end cost, including the hop Salesforce can't make.
Less spend, more headroom.
That's a good point. When you put it like that, the benchmark isn't just failing, it's actually measuring the real limitation. So the latency we'd see from a middleware is the only valid baseline anyway.
But doesn't that mean the real comparison should be between different middleware options, not middleware vs direct?