@kapa.ai I have migrated the Airbyte data and restored on another server. All of the components are running, except the worklaod launcher. TO resolve the issue I had to upgrade the Airbyte version from 1.6.0 to 1.7.0. Now after upgrade dagster user deployment which is running on same server is anot able to connect to the airbyte. I have deployed both using helm charts. Dagster tried to communicate internally with Airbyte using these envs:

- name: AIRBYTE_HOST
    valueFrom:
      secretKeyRef:
        name: dagster-secret
        key: AIRBYTE_HOST
  - name: AIRBYTE_PORT
    valueFrom:
      secretKeyRef:
        name: dagster-secret
        key: AIRBYTE_PORT
  - name: AIRBYTE_USER
    valueFrom:
      secretKeyRef:
        name: dagster-secret
        key: AIRBYTE_USER
  - name: AIRBYTE_PASS
    valueFrom:
      secretKeyRef:
        name: dagster-secret
        key: AIRBYTE_PASS

The Airbyte host value is

airbyte-airbyte-server-svc.data-services.svc.cluster.local

. Here are the logs for the Dagster user deployment:

ERROR - Request to Airbyte API failed: 403 Client Error: Forbidden for url: <http://airbyte-airbyte-server-svc.data-services.svc.cluster.local:8001/api/v1/workspaces/list>

Previously, I was using webapp svc url instead of server

The knowledge sources confirm that from 1.7.x onward Airbyte is consolidating the

webapp

into

server

, and that this change primarily affects ingress and how traffic is routed to

airbyte-server

(and

airbyte-connector-builder-server

) rather than introducing a new authentication model. [Breaking changes; Ingress 1.7+] However, they do not provide specific guidance about: • Using Dagster’s

dagster-airbyte

integration against Airbyte 1.7.x • 403 responses from

/api/v1/workspaces/list

when calling

airbyte-server

directly inside the cluster So I can’t definitively say from the docs alone why your Dagster pod is now getting

403 Forbidden

. What the docs do say that’s relevant: 1. Webapp → Server change (1.6 → 1.7) ◦ 1.7 starts removing the

webapp

service and moving its functions into

server

. [Breaking changes] ◦ Ingress and any external routing that previously pointed at

webapp

must be updated to point at

airbyte-server-svc

(and

airbyte-connector-builder-server-svc

for the Connector Builder). [Ingress 1.7+; GitHub issue 61677] 2. Known 1.7 issues are about Connector Builder / ingress ◦ The documented 1.7 “breaking change” and known issues are about 403s in the Connector Builder UI when ingress is not updated, not about internal service-to-service calls. [Known issues 1.7; Ingress 1.7+] 3. Dagster integration expectations ◦ The Dagster example uses

AIRBYTE_HOST

and

AIRBYTE_PORT

to talk directly to the Airbyte API; it assumes a host/port where the Airbyte API is reachable and doesn’t mention any special auth beyond what the API itself requires. [Dagster integration] Given that, from the docs I can only suggest checks at a high level: • Verify that

AIRBYTE_HOST

and

AIRBYTE_PORT

in your Dagster deployment now point to the same host/port you would use to reach the Airbyte API (the

airbyte-server

service and its port). In 1.7, the API is served by

server

, not

webapp

. [Ingress 1.7+] • Confirm that whatever authentication you previously used (if any) is still valid after the migration/restore; the docs don’t describe a change here, but a 403 suggests the request is reaching the server and being rejected, not blocked by networking. • Double‑check that your Helm upgrade completed cleanly and that you’re not still routing some traffic through a leftover

webapp

service or ingress rule; the docs emphasize that misconfigured ingress around this change can cause 403s. [Breaking changes; Ingress 1.7+] Because the knowledge sources don’t include details on 403s from

/api/v1/workspaces/list

in this Dagster‑to‑server scenario, I can’t provide a precise fix from documentation alone. If possible, I’d recommend: • Checking the Airbyte

server

logs around the time of the 403 to see the exact error message. • Comparing how you reach the API successfully (e.g., via port‑forward or ingress) with what Dagster is using, and aligning `AIRBYTE_HOST`/`AIRBYTE_PORT` with that working path. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai Where can I get the workspace ID?

You can get the workspace ID in two main ways: 1. From the Airbyte UI Go to your organization/workspace settings: • In the UI, click Settings → General (or Settings → Organization → General, depending on version). • You’ll see a list of workspaces; each entry includes its region and internally has a

workspaceId

(often visible in the URL or when selecting a workspace). [Multi‑region 1.6; Multi‑region 1.7] 2. Via the Public API a. List all workspaces

curl -X GET "<YOUR_WEBAPP_URL>/api/public/v1/workspaces" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json"

This returns a

data

array; each item has a

workspaceId

,

name

, and

dataResidency

. [API access config; List workspaces] Example response:

{
  "data": [
    {
      "workspaceId": "b5367aab-9d68-4fea-800f-0000000000",
      "name": "Finance Team",
      "dataResidency": "auto"
    }
  ]
}

b. Get a specific workspace by ID If you already know the ID and want to confirm it:

curl -X GET "<YOUR_WEBAPP_URL>/api/public/v1/workspaces/{workspaceId}" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json"

This returns that workspace’s details, including

workspaceId

. [Multi‑region 1.6] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.