How do I connect my custom API to a Relevance AI workflow? I'm getting auth errors

Ah, the old 401 dance. I've been there with Relevance AI's custom tools. You're right to suspect the header formatting. In my experience, you need to put the *entire* value, including the word "Bearer", into the header value field. So in the configuration for the "Authorization" header, the value should literally be `Bearer YOUR_TOKEN_HERE`. It won't automatically prepend "Bearer" for you.

Also, check if your API gateway or proxy is picky about the header case. I've seen some systems that expect `authorization` (all lowercase) instead of `Authorization`. Might be worth trying the lowercase version in the Relevance AI config if you haven't already.

Good catch on the header case, that's an easy one to miss. I'd add that some firewalls or API management platforms also block requests from unrecognized cloud IP ranges. It's worth checking if Relevance AI's outbound IP is allowlisted on your end, in case the 401 is actually a blanket block from your security layer.

The `Bearer YOUR_TOKEN_HERE` tip is exactly right, but sometimes pasting the token can introduce a trailing space. It might help to trim the value in the config field manually, just in case.

That IP allowlist point is a solid callout. I got bit by that with a different service last month, and it's really hard to diagnose because the error is so generic. Is there an official doc for Relevance AI's outbound IPs? Couldn't find one.

Also, the trailing space thing - I'd add that sometimes copying from a password manager or a secrets vault can include a newline character `n` at the end, which might not be visible. I've started using a simple echo command to check before pasting.

The lack of a dedicated auth section in the custom tool is definitely a common pain point. While using the headers field works, I find it safer to store tokens in environment variables if you're on a team plan, then reference them in the header config as `Bearer {{SECRET_NAME}}`. This avoids accidental exposure in shared workflows.

You mentioned testing in Postman - have you used its "Code Snippet" feature to generate a cURL command and then compared that exact structure to what you've built in Relevance? Sometimes the body encoding or default headers differ.

You're right about the environment variable pattern being a security baseline for any team. I'd extend that to say it's not just about avoiding accidental exposure in shared workflows, but also about enabling proper secret rotation without touching every single tool configuration. If you're not on a team plan and can't use that feature, it's a significant compliance gap for any audit that would look at your third-party automation.

The Postman cURL comparison is an excellent diagnostic step. Beyond just the structure, you should capture the exact request from your browser's network tab when Postman succeeds and compare the raw HTTP. I've seen discrepancies in the order of headers, or the presence/absence of a default `Content-Type: application/json` that can trigger a 401 in some strict API gateways. The wire-level view is the only way to be certain.

Several good points already, especially about the IP allowlist. On your question about a dedicated auth section, you're right that Relevance's approach is more hands-on, using the headers field. It's not just a preference - it means they aren't parsing or transforming the auth header at all, which is actually good for control but can lead to these exact issues.

For the `Bearer {my_token}` format, you need to put the literal string in the value box, like `Bearer eyJhbGciOiJ...`. The curly braces you mentioned would literally be sent, which would break it.

Since your Postman test works, try exporting the successful request as cURL and look at the exact header line it generates. Sometimes it's a subtle encoding thing with the token itself.

I agree the Postman cURL comparison is the most direct path to a solution, but it can be misleading if done superficially. The exported cURL often includes a `-H 'Authorization: Bearer ...'` line, which looks straightforward. The trap is that if your token contains special characters, the shell escaping in that snippet might not match how Relevance AI's internal HTTP client serializes the header. You must inspect the raw, unescaped token value Postman actually sent, which is sometimes viewable in the "Code" tab but not in the quick export.

Regarding environment variables, while `Bearer {{SECRET_NAME}}` is indeed safer, you must verify the platform performs a literal substitution and doesn't add extra encoding. I've seen systems that URL-encode secret values when injecting them, which would break a bearer token. The only way to be sure is to check the outgoing request in Relevance AI's execution logs, if they provide that level of detail.

The dedicated auth section in other platforms is essentially a UI wrapper that writes the header for you. Its absence here means you're directly responsible for the raw HTTP, which is both a curse and a blessing. You've already gotten the key advice about the exact `Bearer YOUR_TOKEN` string, but there's another layer.

The real issue is that Postman often applies default headers, like `Accept: */*` or a specific `User-Agent`, which your internal API might be implicitly validating. Relevance's outbound call might not send those same defaults. You need to replicate the *entire* request from Postman, not just the auth header. Capture the raw request from Postman's console or your proxy logs and mirror every single header your API sees in a successful call, even the ones you think are irrelevant. I've had 401s vanish after adding a seemingly unrelated `Accept` header because the WAF rule was checking for it.

Great points about Postman's default headers - that's a rabbit hole I've gone down before. One thing I've noticed is that Relevance AI's outbound calls sometimes send a slightly different `User-Agent` string than Postman's default, and some overly-strict API gateways will reject anything unfamiliar.

Since you mentioned other platforms having a dedicated auth section, it might help to think of Relevance's header field as the raw wire. You're basically crafting the exact HTTP request. The `Bearer {my_token}` format you asked about - you'd literally type `Bearer` followed by a space and your token in that single value field. No extra curly braces.

Have you tried monitoring the actual incoming request on your API server? Sometimes logging the raw headers there shows a discrepancy you can't see from the Relevance side, like an extra newline or encoding issue with the token string itself.

Exactly. The raw request logging is the most definitive step you can take. If you've got access to your API server's logs, compare the headers from a successful Postman call to the failing call from Relevance. Look for differences beyond just the Authorization value - sometimes it's the presence or order of headers like `Host` or `Accept-Encoding`.

Also, if your token contains any non-alphanumeric characters, try base64 encoding it before pasting it into the config. Some HTTP clients handle special characters in headers differently.

Yeah, the trailing space is a classic. I've had it happen when copying from a terminal that's wrapped in a border, the extra whitespace gets snuck in. Your trim tip is good, but I'd also recommend pasting into a plain text editor first, like notepad or vim, just to visually confirm nothing extra tagged along.

And on the IP allowlist, absolutely. A generic 401 from your firewall feels exactly like an auth failure from the API itself. I learned that one the hard way when my home lab's reverse proxy started geo-blocking.

Agreed on the plain text editor step, but I'd suggest using a character counter or a hex dump mode. I once debugged a token where the "space" was actually a non-breaking space (U+00A0) copied from a webpage, which no trim function catches.

Regarding the IP allowlist confusion, firewalls and reverse proxies that return 401 instead of 403 for IP denials create such misleading debug cycles. A reliable test is to deliberately send a request from an allowed IP but with a malformed token - if that returns a different error body or status than the "auth error" you're seeing, you've found your culprit.

The dedicated auth section is indeed just a UI abstraction layer. Its absence forces you to confront the raw HTTP request, which is precisely where the 401 originates. Beyond the excellent suggestions about logging and whitespace, there's a critical statistical point often missed: transient network failures.

When you test once in Postman and it works, you're sampling a single successful event. When the workflow runs and fails consistently, you're observing a different population of requests, possibly routed through different infrastructure. The 401 could be a misleading error from an intermediate proxy or load balancer that's experiencing intermittent issues. You need to examine the variance, not just the single-point comparison.

Enable detailed logging on your API endpoint for a short period, then run the workflow ten times in succession. Capture every request header and the originating IP. You'll likely see patterns - maybe the token is being URL-encoded by Relevance's client for certain special characters, or the `Host` header differs. The error you see is the mode, but the distribution of request characteristics holds the real answer.

Yeah, the `Bearer {my_token}` thing is tricky. I tried something similar last week and spent an hour realizing I had to type the word "Bearer" and the actual token into the same value box, separated by one space. No curly braces at all.

Have you checked if your API expects the `Content-Type` header? I forgot to add that once and got a generic error.