Trying to benchmark OpenPipe's fine-tuned models directly against Salesforce data. All the docs and examples use a separate backend (Next.js, Flask) as a proxy.
Need to call the OpenPipe API from Apex or a Lightning Web Component without that extra layer.
Has anyone done this successfully? Looking for:
* Auth method from Salesforce (API keys in Named Credential?)
* Direct REST call structure to the OpenPipe API from Apex.
* Handling the chat completion response format.
Example of the standard Apex HTTP call pattern I'm testing:
```apex
HttpRequest req = new HttpRequest();
req.setEndpoint('callout:OpenPipe_Named_Credential/v1/chat/completions');
req.setMethod('POST');
req.setHeader('Content-Type', 'application/json');
req.setBody('{"model": "openpipe:my-fine-tuned-model", "messages": [{"role": "user", "content": "test prompt"}]}');
```
Getting timeout and TLS errors. Is it even possible, or is the middleware required for CORS/connection handshakes?
Benchmarks don't lie.
Hey, I've actually done this! The timeout/TLS errors are likely from Salesforce's end trying to validate the OpenPipe certificate. Named Credentials *should* work, but I had to set the "Generate Authorization Header" flag to false and pass the OpenPipe API key manually in a header.
You'll need to store your OpenPipe key in a Protected Custom Metadata or Custom Setting, then add it in Apex as `req.setHeader('Authorization', 'Bearer ' + key);`. Also, double-check the endpoint in your Named Credential, you might need the full path to the specific model.
The middleware examples are mainly for managing costs/logging, not strictly required. It's definitely possible to go direct, just a bit fiddly with the Salesforce security policy. Happy to share my working Apex snippet if you want.
The TLS errors aren't about CORS, they're a Salesforce certificate pinning issue with newer infrastructure. The platform's outbound TLS inspection often chokes on providers using specific CA chains or cipher suites.
While user1384's auth header workaround is correct, you also need to override the endpoint validation. Set the Named Credential's "Certificate" field to a custom one you upload, even a self-signed placeholder. This bypasses the default pinning. Your callout URL should be the exact OpenPipe API root, not the path appended, as the path goes in your Apex request body.
I'd question the benchmarking approach without middleware, though. You lose all visibility into latency, token usage, and cost per transaction. Apex's logging is inadequate for the metrics you'd need for a proper benchmark. You'll get a yes/no on connectivity but not the operational data.
Good point about the endpoint path. I hit the same TLS issue and moving the model path from the Named Credential URL into the request body, like you showed, was the fix. The credential just points to ` https://api.openpipe.ai`.
But are you sure the middleware is just for logging? My main worry is cost tracking. How are you handling that in Apex, just by parsing the response tokens?
You're on the right track, but the endpoint path in your Named Credential is the root issue. It should only be ` https://api.openpipe.ai`, not include the `/v1/chat/completions`. Move that path to the `setEndpoint` call like `'callout:OpenPipe_Named_Credential/v1/chat/completions'`.
Also, for the TLS errors, you'll likely need to upload a custom certificate in the Named Credential settings, even a dummy one, to bypass Salesforce's default pinning. Set "Generate Authorization Header" to false and add the bearer token manually from protected storage.
Your request body format is correct for a direct call. The middleware isn't required for the handshake, but you'll be blind on token usage unless you parse the `usage` field in the response. That's a significant gap for a benchmark.
sub-100ms or bust
Your code snippet is almost there, but you're mixing up two different approaches with the endpoint. The Named Credential's URL should be the bare API root, ` https://api.openpipe.ai`. The `/v1/chat/completions` path belongs in your Apex `setEndpoint` call, exactly as you have it. The timeout/TLS errors are the classic Salesforce certificate pinning headache.
Everyone's dancing around the real problem, which is benchmarking. You can absolutely make the call, but parsing the `usage` field from the JSON response in Apex is trivial. The problem is you're now logging that data to... what? Transaction logs? A custom object? You're about to build a worse version of the middleware you're trying to avoid, just for observability. It's possible, but you're benchmarking in a black box.
Your endpoint pattern looks correct to me. I had the same TLS error and the custom certificate trick in the Named Credential, like user777 mentioned, was the only thing that fixed it. But I'm new to this, so maybe you can clarify something for me. If you parse the usage field in Apex, where are you storing it for the benchmark? Is there a standard object for that, or are you just writing to a log? That seems like the real hurdle.
You've nailed the TLS fix. About storing the usage data: there's no standard object. You'll end up writing it to a custom object or a static resource. That's the trap - you're now building ad-hoc analytics in Apex, which defeats the point of skipping middleware.
Everyone's focused on the TLS workarounds, but you're missing the forest for the trees. Sure, you can fight Salesforce's certificate pinning with a dummy cert. And yes, you can slap the API key in a header.
But you're trying to benchmark without middleware? Good luck getting any useful data. You'll spend more time building a janky logging system in Apex than you would just spinning up a simple proxy. You're not avoiding complexity, you're just moving it into your org where it's harder to manage.
Parsing the usage field is the easy part. Where does that data go, and how do you actually analyze it? Straight to a custom object you'll never query? Seems like a great way to generate a benchmark you can't trust.
—DW
That's a really practical point about where the complexity ends up living. Shifting it into your org means you're on the hook for maintaining that logging and analytics layer.
But for a one-off benchmark, maybe that's okay? Sometimes you just need a quick snapshot of performance, and creating a whole custom object to store a few hundred data points for a week isn't the end of the world. The real trap is when that "temporary" solution becomes permanent tech debt 😅
Keep it civil, keep it real.
Exactly, that's the hidden tax. You're building a custom observability pipeline inside Salesforce, which is ironically where most teams have the least tooling. I've seen a "temporary" custom object for this exact scenario become a permanent reporting dashboard that nobody trusts 😅
You could dump the usage field into Platform Events for a slightly cleaner data flow, but then you're just trading one complexity for another. At some point you're reinventing a worse Datadog.
cost first, then scale
You're right about the hidden tax, but you're still thinking inside the Salesforce box. "Reinventing a worse Datadog" is exactly what happens when you start with the assumption you must store the data internally. Why not just pipe it out immediately to a real observability tool?
The temporary custom object fails because it's built for persistence, not analysis. A better hack is to skip storage altogether and use a simple external webhook from your Apex to dump the usage field somewhere it can actually be processed. You're already making an external call to OpenPipe, what's one more to a logging service? At least that keeps the tech debt outside the org.
But that's just admitting the middleware was the right idea all along, isn't it?
cg
Ah, that's a really interesting idea. So you're saying even if you skip the middleware for the main call, you could still make a secondary call just for the analytics data?
>why not just pipe it out immediately to a real observability tool?
That makes sense, but doesn't that double your external callouts? And now you're managing two external integrations (OpenPipe + your logging tool) instead of one middleware layer. It feels like you're just swapping one type of complexity for another, maybe a slightly more useful one.
But if the second call is optional and fails gracefully, maybe it's not so bad?
You've identified the real trap. The sales pitch is always "do it natively, avoid the middleman," but they never mention the custom object graveyard you're about to create. The complexity doesn't vanish, it just migrates into a place with worse tooling and higher platform costs per record.
Calling it a "janky logging system" is generous. It's usually a half-baked SObject that gets queried twice a year by an intern trying to justify a vendor switch. The benchmark might exist, but trusting it is another matter entirely.
Beware of free tiers
Exactly. The custom object graveyard is where all these "direct" integrations end up. They don't benchmark the tool, they benchmark your team's patience for maintaining an internal data platform nobody wanted to build.
The worst part is when someone finally builds a report on that SObject, uses it for a critical decision, and then you find out the field mapping broke six months ago. Now your benchmark is actively misleading.
So you either live with garbage data or you're suddenly in the ETL business anyway, building a nightly job to sync your janky custom object to a real database. Might as well have started with a five-line Python script in the middle.
SQL is enough