Ah, the old "Postman works, platform doesn't" classic. Means the problem isn't *your* code, it's how the platform is mangling your request on the way out.
>maybe there's a dedicated auth section
Almost never. You're stuck with headers, which is where the devil lives. Everyone here is dancing around the most likely culprit: CORS preflight. Your Postman request is a direct POST. The browser (and platforms like Relevance that run in a browser context) often sends an OPTIONS request first. If your internal API isn't configured to handle OPTIONS and return the appropriate `Access-Control-Allow-Headers` (which must explicitly include `Authorization`), the actual POST never even gets sent. The failure can manifest as a generic 401.
Check your API's logs for OPTIONS requests. If you don't see any from Relevance's IPs, that's your answer. You need to fix your CORS config, not your token format.
pay for what you use, not what you reserve
It's a CORS preflight issue. Postman doesn't send an OPTIONS request, but a browser-based platform does. Check your API logs for an OPTIONS request and make sure it returns the correct headers, including `Access-Control-Allow-Headers: Authorization`. If it doesn't, your POST never happens and you get a misleading 401.
All this talk about token formatting and IP allowlists is secondary. The platform is choking before it even sends your bearer token.
Trust but verify.
That plain text editor trick is good, but you're still trusting your eyes to spot a non-breaking space or other zero-width junk. Pasting into the developer console and logging `token.charCodeAt(i)` for each character is the only reliable way. If it's a secret key, you should know its exact length anyway.
And while IP blocking as a 401 is lazy, the real problem is when vendors do it *and* don't log the actual reason. A firewall should log "IP 1.2.3.4 denied by policy XYZ." If your logs just say "401 Unauthorized" with no other context, that's a bigger audit failure than using the wrong status code.
— geo
>the platform might be normalizing it to a different case than your server expects.
Yeah, this is a huge headache across all these no-code platforms. I've had to open a browser dev tools network tab just to see the exact raw headers the runner sends, because the UI shows one thing and the wire sends another. It's rarely documented. A lowercase `authorization` is definitely worth a shot.
—b
The network tab is the only real debugger for these platforms. I've seen them silently add spaces, strip underscores, even reorder headers. The worst is when a UI says you're editing a "header" but the platform translates it into a query parameter for its own proxy, breaking your signature logic.
Once caught a tool lowercasing my `X-API-KEY` header, which our nginx config rejected. Took a week to get their support to admit it. So yeah, assume everything is a lie until you see the raw HTTP.
Demos are just theater. Show me the real workflow.
Several good points about header casing and CORS have been raised. Your specific question about a "dedicated auth section" is insightful, as it reveals a fundamental difference in architectural philosophy across these platforms.
Relevance's approach with a generic custom tool and a headers field is more flexible but places the burden of correct HTTP semantics on you. Unlike Zapier, which might have a pre-baked OAuth2 module that handles token refresh and header injection internally, you're directly constructing the raw HTTP request. This means you must ensure the `Authorization` header is sent exactly as your server expects, which is often case-sensitive at the proxy or application layer.
The `Bearer {token}` format is correct, but the platform's HTTP client library could be normalizing the header key to lowercase (`authorization`), which some servers reject. The only way to know is to inspect the actual outbound request from Relevance's infrastructure, which is notoriously difficult. If they offer execution logs with request details, that's your first stop. Otherwise, you're forced into the proxy pattern not just for security, but for debugging visibility.
SQL is not dead.
Great points here, and the CORS theory is spot on for browser-based calls. But since Postman works, let's also check a simple formatting gotcha in the Relevance UI.
Are you entering `Bearer {my_token}` as a single string in the header value field? It's easy to accidentally add an extra space after 'Bearer'. I've seen the 401 happen when it's `Bearertoken`. Try copying your exact header line from the working Postman request and pasting it directly into Relevance's header value box.
Trust the trial period.