Is allowed_origins Functioning Correctly in the Prod Environment?

Bugs
1

This topic was automatically generated from Slack. You can find the original thread here.

Hello! is allowed_origins working well in prod environment? it seems that is refusing my requests today

2

Can you elaborate please?

3

Hi , thanks for checking.
We’re seeing a production-only issue with Connect API requests that appears related to CORS / allowed_origins.
What we observe
Connect token is successfully created server-side and returned to frontend.
• Token payload includes expected fields (token, expires_at, and project_id).
• Frontend then calls:
• GET /v1/connect/{project_id}/components/{component_slug}
• Browser fails with CORS:
No ‘Access-Control-Allow-Origin’ header is present on the requested resource
• sometimes shown as net::ERR_FAILED after preflight.
Key details
• This works in local development, fails in production.
allowed_origins is explicitly set when creating the Connect token, including the production app origin and https://connect.pipedream.com.
We validated token TTL/timezone and it does not look like an expiry issue.
• We also validated project_id is present and no longer empty (we previously fixed a double-slash path issue caused by missing project id).
• We tested multiple recent SDK versions with the same outcome in production.
Why we suspect platform-side CORS behavior
When testing the Connect endpoint path from production context, preflight behavior appears inconsistent with expected CORS headers for configured origins, even though the token creation call accepts allowed_origins.
Could you confirm:
Whether there were recent changes in Connect API CORS handling for production origins?
If allowed_origins on token creation is the only required setting for browser calls to /v1/connect/{project_id}/components/*?

  1. If there are known cases where preflight can return 200 but still omit Access-Control-Allow-Origin?
  2. Any additional headers / account-level settings required for production domains?
    If helpful, I can share sanitized request/response traces (without sensitive identifiers).
4

P.D.: We didn’t deploy any functional changes to the Connect integration on our side before this started; it simply stopped working in production from one day to the next.

5

Can you show me the payload when creating the Connect Token?

6

Sure — here is the sanitized payload we send when creating the Connect Token.

Request

  • Method/URL: POST https://api.pipedream.com/v1/connect/{project_id}/tokens
  • Headers:
json
{
  “Authorization”: “Bearer <oauth_access_token>“,
  “X-PD-Environment”: “production”,
  “X-PD-Project”: “<project_id>“,
  “Content-Type”: “application/json”
}
  • Body:
json
{
  “external_user_id”: “<tenant_or_user_id>“,
  “externalUserId”: “<tenant_or_user_id>“,
  “allowed_origins”: [
    “https://<our-production-app-origin>“,
    “https://connect.pipedream.com”
  ],
  “allowedOrigins”: [
    “https://<our-production-app-origin>“,
    “https://connect.pipedream.com”
  ]
}

Response (from our backend to frontend, sanitized)

json
{
  “token”: “ctok_xxx”,
  “expires_at”: “2026-03-04T13:43:09.117+00:00”,
  “project_id”: “<project_id>”
}

Then the frontend calls:
GET /v1/connect/{project_id}/components/{component_slug}
and that is where we hit the CORS issue in production.

7

Btw, what is https://connect.pipedream.com/? That is not needed for anything.

And you’re currently testing from whatever value you defined for "https://<our-production-app-origin>"?

8

And you’re passing both external_user_id and externalUserId as well as allowed_origins and allowedOrigins?

9

You’re right:

  • https://connect.pipedream.com ive added to check it that was the problem
  • Yes, we are testing from the exact production frontend origin defined in allowed_origins.

And yes, currently we are sending both key variants:

  • external_user_id + externalUserId
  • allowed_origins + allowedOrigins

We added both for compatibility while debugging.

10

If you’re using the REST API, which it looks like you are, you should send snake_case. Check out the docs: Create Connect token - Pipedream

11

Thanks, we can switch to snake_case only, but I’m not confident that is the root cause.
Our reason is that this exact integration pattern (including current token flow) had been working in production and then started failing without a functional change on our side. The current failure mode is browser CORS enforcement on the Connect component fetch, not token creation failure itself.
So we’ll align payload format to docs to remove ambiguity, but based on behavior and timing we suspect there may also be a change from your side

12

Can you give that a shot? We haven’t shipped any changes recently that would impact what you’re running into, so I suspect it’s related either to the payload or a mismatch in the domain you’re defining vs where it’s actually running.

13

same error:

162777aa-c6b6-4b9f-a7e3-bc00e869261b:1 Access to fetch at ‘https://api.pipedream.com/v1/connect/proj_BgszeE0/components/hubspot-get-contact’ from origin ‘https://platform.nexus-solutions-lab.com’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.Understand this error
vendors-cda5593d1daf6395.js:56 GET https://api.pipedream.com/v1/connect/proj_BgszeE0/components/hubspot-get-contact net::ERR_FAILED

14

And the actual domain of the page matches the domain you defined in allowed_origins?

15

Yes, ive tried also wildcard to check if there was some weird redirect

16

Yea we don’t support a wildcard

17

but that was a test, the current status is that url hardcoded in the parameter

18

image.png
image.png622×118 13.6 KB

19

in local all is working in pro development and allowed origins localhost

20

Any update ?