https://linen.dev logo
Join Slack
Powered by
<@U04S8PLJWMT> Failed to save Google Ads Test due ...
# replication-ask-ai
k
@kapa.ai Failed to save Google Ads Test due to the following error: errors.http.default
k
The knowledge sources don’t contain a direct description of the exact error message you’re seeing for Google Ads (“Failed to save Google Ads Test due to the following error: errors.http.default”), but they do show similar HTTP-layer errors in Airbyte and some open issues around Google Ads. A few relevant points: 1. Generic HTTP error wrapper Airbyte’s UI can surface HTTP errors in a generic, localized form like 
errors.http.default
, with the real cause in the underlying HTTP status and message. An example from another issue shows a 409 error wrapped this way, with the real message being “Failed to access database. Check the server logs for more information.” [[DB 409 issue](https://github.com/airbytehq/airbyte/issues/54150)] This suggests your Google Ads “Test” failure is likely an HTTP error (4xx/5xx) coming from either: - The Airbyte backend (e.g., failing to persist/update the source), or - The Google Ads connector/API, which then causes the platform call (e.g., 
updateSource
) to fail. 2. Known Google Ads source issues - There is an open issue where Google Ads “Check connection” passes at the connector level but the platform fails with 
422 Unprocessable Entity
on an internal 
updateSource
call after the check, specifically for 
source-google-ads
on OSS K8s via 
abctl
. [[Google Ads 422 issue](https://github.com/airbytehq/airbyte/issues/60900)] - Another open issue reports Google Ads authentication problems that work fine with another tool, suggesting a connector/platform-side problem rather than credentials. [[Google Ads auth issue](https://github.com/airbytehq/airbyte/issues/63374)] Your symptom (“Failed to save Google Ads Test…”) is consistent with this class of platform-side failure when saving/updating the source after a test. 3. What you can do next (based on available info) Since the docs and issues don’t give a concrete fix for your exact message, the best next steps—grounded in the similar issues—are: - Check server logs around the time of the failure (especially 
airbyte-server
logs) to see the actual HTTP status and backend error message, as recommended in the 409 example. [[DB 409 issue](https://github.com/airbytehq/airbyte/issues/54150)] - Confirm your deployment/version and connector version and compare with the affected setups: - OSS vs Cloud - 
source-google-ads
version (e.g., 3.7.10 is mentioned in the 422 issue). [[Google Ads 422 issue](https://github.com/airbytehq/airbyte/issues/60900)] - If you’re on OSS and can reproduce consistently, consider: - Trying the same config on Airbyte Cloud (if possible) to see if it’s platform-specific, as in the 422 issue. [[Google Ads 422 issue](https://github.com/airbytehq/airbyte/issues/60900)] - Opening or updating a GitHub issue with: - Airbyte version and deployment method - Google Ads connector version - Full error JSON from the browser dev tools (Network tab) and the corresponding server logs. Because the knowledge sources don’t include a specific resolution for “Failed to save Google Ads Test … errors.http.default” on the Google Ads connector, I can’t point to an exact fix, only to these related patterns and troubleshooting steps.
This error message (
errors.http.default
) is a generic HTTP error wrapper from the Airbyte UI; it doesn’t by itself indicate the root cause. In similar cases, a few relevant patterns show up in the provided sources: 1. HTTP 409 / database conflict A generic 
errors.http.default
with status 409 (
ConflictException
) has been observed when Airbyte fails to access its internal database (e.g., schema mismatch, incompatible version). Upgrading server components (bootloader, server, webapp, worker) from 1.3.1 to 1.5.1 resolved such an issue for another user.[\[DB 409 issue\]](https://github.com/airbytehq/airbyte/issues/54150) 2. Google Ads connector quirks (Check Connection / save step) - There is an open issue where a Google Ads source works on Airbyte Cloud but fails in OSS when the platform attempts an internal 
updateSource
after a successful connector check, returning 
422 Unprocessable Entity
from the platform API.[\[GAds 422 issue\]](https://github.com/airbytehq/airbyte/issues/60900) - Another user reported Google Ads check failing intermittently when editing/creating a source; repeated retries eventually worked with no change in config.[\[Forum GAds test\]](https://discuss.airbyte.io/t/3590) 3. Potential Google Ads auth / account hierarchy specifics An open issue suggests some Google Ads auth problems may be related to how 
customer_id
/ 
login_customer_id
are set in the Google Ads client.[\[GAds auth issue\]](https://github.com/airbytehq/airbyte/issues/63374) However, the shared logs don’t show a definitive fix yet. Given only the on-screen message “Failed to save Google Ads Test due to the following error: errors.http.default”, the knowledge sources do not provide enough information to say exactly which of these applies to your instance. The platform could be failing: - On a database-level conflict (e.g., version or schema issue) when saving the source, or - On an internal 
updateSource
call related to Google Ads token/metadata handling. What you can do next (based on the docs and issues): 1. Check the HTTP status and server logs - In the browser dev tools, inspect the failing request (likely 
/api/v1/sources/create
or 
/api/v1/sources/update
/ 
instance_configuration
) to see the HTTP status (409, 422, etc.) and response body. - Cross‑check with your 
airbyte-server
logs for the matching 
requestId
if present, as that’s where the root error is surfaced in similar cases.[\[DB 409 issue\]](https://github.com/airbytehq/airbyte/issues/54150) 2. Confirm Airbyte / component versions - If you’re on a relatively old OSS version, consider upgrading to a newer server/webapp/worker set, since at least one 409 / DB access error was fixed simply by upgrading.[\[DB 409 issue\]](https://github.com/airbytehq/airbyte/issues/54150) 3. If using OSS with Google Ads - Be aware there is a known bug where Google Ads check passes but saving (internal 
updateSource
) fails with 422; this is specific to OSS (abctl/K8s) and does not affect Cloud.[\[GAds 422 issue\]](https://github.com/airbytehq/airbyte/issues/60900) - In that case, capturing the exact HTTP status and body from the failing platform call will be important if you open or join an issue. Because the sources don’t include a direct, step‑by‑step fix for your exact message in the context of Google Ads, I can’t give a definitive resolution, only these likely directions based on similar, documented cases.
k
@kapa.ai what container would have logs related to this error?
k
A message from kapa.ai
Most likely you’ll want to look at: 1. The Airbyte server / platform logs This is where HTTP errors like 
errors.http.default
and database or 
updateSource
failures are surfaced. For local Docker OSS, an example from a similar “localhost refused to connect” case shows checking 
airbyte-server
with:
Copy code
bash    docker logs airbyte-server
[[Forum localhost error](https://discuss.airbyte.io/t/2122)] 2. The job/connector pod or container running the Google Ads check In K8s/abctl deployments, Google Ads check/discover jobs run in dedicated pods like 
e-google-ads-check-...
or 
...-discover-...
, and their logs show the connector and sidecar behavior around check/save operations. [[Google Ads 422 issue](https://github.com/airbytehq/airbyte/issues/60900)] 3. Per‑job logs in the UI For a failing “Test / Check connection”, you can also open the connection’s Job History → View logs to see the full logs for that check job. [[Browsing logs](https://docs.airbyte.com/platform/operator-guides/browsing-output-logs)] If you share whether you’re on Docker or K8s, I can narrow it further, but the knowledge sources don’t provide a more specific container name for your exact error.
k
@kapa.ai When adding the google ads connection, it has a note to 
When configuring your OAuth app, set the callback or redirect URL to *<https://airbyte.k8s.haus/auth_flow>.*
Is there aditional configuration in the standard helm deployment that is required for oauth with google to work for this connection?
k
A message from kapa.ai
A message from kapa.ai
There’s no doc that calls out Google Ads–specific extra Helm config, but there is required ingress/routing config for OAuth flows in general, and that’s what makes the 
<https://airbyte.k8s.haus/auth_flow>
URL work. From the available docs: 1. Ingress must be configured and reachable on your OAuth redirect host For Helm deployments, you need an ingress that routes your public hostname (e.g. 
airbyte.k8s.haus
) to the Airbyte services. The Helm chart examples show how to do this; for a basic setup (no Keycloak) you at least need:
Copy code
yaml    ingress:      enabled: true      className: "nginx"      hosts:        - host: <http://airbyte.example.com|airbyte.example.com>  # replace with your domain, e.g. airbyte.k8s.haus          paths:            - path: /              pathType: Prefix              backend: server                 # airbyte-server (UI + API)            - path: /connector-builder              pathType: Prefix              backend: connector-builder-server
[[Helm ingress basic](https://docs.airbyte.com/platform/next/deploying-airbyte/integrations/ingress#option-1-use-airbytes-helm-chart)] Or, if you “bring your own” ingress, you must manually route the host and paths to the correct services. [[Enterprise ingress](https://docs.airbyte.com/platform/next/enterprise-setup/implementation-guide#set-up-ingress-in-airbyte)] As long as 
<https://airbyte.k8s.haus>
is correctly routed to 
airbyte-server
, the 
/auth_flow
path used in the redirect URL will be handled by Airbyte’s OAuth implementation; there’s no separate service for it in the docs. 2. No extra Helm values specifically for Google OAuth are documented The OAuth docs describe how OAuth works (you register a client, set redirect URI, then Airbyte handles the flow), but they don’t mention any additional Helm values or special configuration for Google Ads beyond: - Registering the OAuth app and setting the redirect URI exactly as shown in the UI. - Entering Client ID and Client Secret in the connector config. [[Using OAuth](https://docs.airbyte.com/platform/next/using-airbyte/oauth)] The connector‑builder OAuth docs also assume that once the redirect URL is reachable, Airbyte manages the consent and token exchange flow internally. [[Builder OAuth 2](https://docs.airbyte.com/platform/next/connector-development/connector-builder-ui/authentication#oauth-2)] So, based on the docs: - Yes, you must ensure ingress is correctly configured so that 
<https://airbyte.k8s.haus>
(including 
/auth_flow
) reaches 
airbyte-server
. - No additional, Google‑specific Helm configuration is documented beyond that; the rest is handled by Airbyte once the redirect URL is valid and reachable. If OAuth still fails after ingress is correctly set up, the next step would be to inspect 
airbyte-server
logs and the browser network trace, but the knowledge sources don’t provide a documented troubleshooting path specific to Google Ads + Helm.
The knowledge sources don’t describe any Google-specific extra Helm configuration beyond standard ingress, so I can’t confirm that anything special is required just for Google Ads OAuth. I can, however, point to what is documented and how it relates to your callback URL. 1. Callback / redirect URL The OAuth docs state that for self‑managed Airbyte you must register your own OAuth app and configure the redirect URI exactly as shown in the Airbyte UI. [[Using OAuth](https://docs.airbyte.com/platform/using-airbyte/oauth)] In your case, that’s 
<https://airbyte.k8s.haus/auth_flow>
. There’s no mention of a different path or extra Google‑specific redirect handling. 2. Ingress / routing requirements For OAuth flows to work, the browser must be able to reach the Airbyte server at that URL. With Helm, this is handled via ingress: - Basic Helm ingress example routes 
/
to the 
server
backend (Airbyte server, which serves UI and API). [[Helm ingress option 1](https://docs.airbyte.com/platform/deploying-airbyte/integrations/ingress#option-1-use-airbytes-helm-chart)] - Enterprise examples show explicit paths for 
/auth
and 
/api/v1/connector_builder/
, but the key point is that your ingress must route the OAuth callback path (
/auth_flow
in your case) to the Airbyte server service. [[Enterprise ingress](https://docs.airbyte.com/platform/enterprise-setup/implementation-guide#set-up-ingress-in-airbyte)] The docs do not show a dedicated 
/auth_flow
path; instead, they rely on the general 
/
→ 
server
routing, which would also cover 
/auth_flow
if you use a 
path: /
with 
pathType: Prefix
. [[Helm ingress option 1](https://docs.airbyte.com/platform/deploying-airbyte/integrations/ingress#option-1-use-airbytes-helm-chart)] 3. No documented extra Helm config for Google Ads The available docs and GitHub issues about Google Ads (including one about a 422 error after check connection) do not mention any additional Helm values or special ingress annotations required specifically for Google OAuth. [[Google Ads 422 issue](https://github.com/airbytehq/airbyte/issues/60900)] So, based on the knowledge sources: - You must register 
<https://airbyte.k8s.haus/auth_flow>
as the redirect URI in your Google OAuth app. - Your Helm ingress must route that path to the Airbyte server (usually covered by a 
/
prefix rule). - There is no explicit documentation of any further Helm‑specific configuration needed for Google Ads OAuth beyond standard ingress and TLS setup. If your ingress already routes all paths (
/
) to the Airbyte server over HTTPS, that should satisfy what the docs describe.
A message from kapa.ai
I’m not seeing anything in the knowledge sources that documents Google‑Ads‑specific Helm settings. Everything described is generic OAuth + ingress behavior. From the docs: - For Helm deployments, you must have ingress configured so that your public Airbyte URL (e.g. 
<https://airbyte.k8s.haus>
) routes to the Airbyte server. A basic Helm V2 example is:
Copy code
yaml   ingress:     enabled: true     className: "nginx"     annotations: {}     hosts:       - host: <http://airbyte.example.com|airbyte.example.com>  # replace with your domain, e.g. airbyte.k8s.haus         paths:           - path: /             pathType: Prefix             backend: server                 # routes to airbyte-server           - path: /connector-builder             pathType: Prefix             backend: connector-builder-server
[[Helm ingress](https://docs.airbyte.com/platform/next/deploying-airbyte/integrations/ingress#option-1-use-airbytes-helm-chart)] Because 
path: /
with 
pathType: Prefix
routes all subpaths to 
airbyte-server
, this also covers 
/auth_flow
. - The OAuth docs say that in self‑managed Airbyte you must: 1. Register an OAuth app with the third‑party provider. 2. Set the redirect URI exactly to what the Airbyte UI shows. 3. Enter the Client ID and Client Secret in the connector, then click the auth button. [[Using OAuth](https://docs.airbyte.com/platform/next/using-airbyte/oauth)] There is no mention of extra Helm values, special services, or additional paths (beyond normal ingress to 
airbyte-server
) required specifically for Google OAuth. So, based on the available docs: - You do need working ingress so that 
<https://airbyte.k8s.haus/auth_flow>
reaches 
airbyte-server
. - There is no documented additional configuration in the standard Helm deployment specifically for Google Ads OAuth beyond that.
A message from kapa.ai
Based on the docs, there is no Google‑Ads‑specific Helm configuration documented. The only requirement is that your Airbyte URL (here 
<https://airbyte.k8s.haus>
) – including the 
/auth_flow
path – correctly routes to the Airbyte server service. With the standard Helm chart, this is normally satisfied by the basic ingress config, which routes all paths under 
/
to the 
server
backend:
Copy code
yaml ingress:   enabled: true   className: "nginx"   annotations: {}   hosts:     - host: <http://airbyte.example.com|airbyte.example.com>  # replace with your domain, e.g. airbyte.k8s.haus       paths:         - path: /           pathType: Prefix           backend: server                 # airbyte-server (UI + API)         - path: /connector-builder           pathType: Prefix           backend: connector-builder-server
Because 
path: /
with 
pathType: Prefix
matches 
/auth_flow
, no extra path is needed for OAuth callbacks. [[Helm ingress](https://docs.airbyte.com/platform/next/deploying-airbyte/integrations/ingress#option-1-use-airbytes-helm-chart)] The OAuth docs only add that, for self‑managed deployments, you must: 1. Register an OAuth app with Google. 2. Set the redirect URI exactly to what the Airbyte UI shows (in your case `https://airbyte.k8s.haus/auth_flow`). 3. Enter the Client ID and Client Secret in the connector and use the UI auth flow. [[Using OAuth](https://docs.airbyte.com/platform/next/using-airbyte/oauth)] The knowledge sources do not mention any additional Helm values, annotations, or special services required specifically for Google Ads OAuth beyond this ingress/redirect setup.
k
@kapa.ai I was now able to authenticate, but when clicking set up source I get An unknown error occurred. (HTTP 504)
k
A message from kapa.ai
A message from kapa.ai
A 504 at “Set up source” means the UI request is timing out somewhere between your browser and the Airbyte backend; the knowledge sources show several similar 504 patterns, but not a Google‑Ads‑specific fix. From those patterns: 1. Where the 504 often comes from In self‑hosted / Helm / K8s setups, 504s are frequently caused by an intermediate proxy or ingress with a 60s default timeout, even when Airbyte itself is configured with higher timeouts: - NGINX ingress with 
proxy-read-timeout
, 
proxy-send-timeout
, etc. needing to be increased. [[504 schema changes](https://github.com/airbytehq/airbyte/issues/55690)] - External proxies (e.g. basic auth proxy) needing 
BASIC_AUTH_PROXY_TIMEOUT
increased. [[Proxy 504](https://discuss.airbyte.io/t/3305)] In the 504 issue for 
/api/v1/web_backend/connections/get
, the user had already increased timeouts on the load balancer, ingress, and Airbyte server, but still saw a 60s cutoff, indicating another component in the path was enforcing that limit. [[504 schema changes](https://github.com/airbytehq/airbyte/issues/55690)] 2. What to check in your setup Based on those examples, for your “Set up source” 504: - Ingress / proxy timeouts If you’re using NGINX ingress, ensure annotations like these are set high enough:
Copy code
yaml      <http://nginx.ingress.kubernetes.io/proxy-connect-timeout|nginx.ingress.kubernetes.io/proxy-connect-timeout>: "600"      <http://nginx.ingress.kubernetes.io/proxy-send-timeout|nginx.ingress.kubernetes.io/proxy-send-timeout>: "600"      <http://nginx.ingress.kubernetes.io/proxy-read-timeout|nginx.ingress.kubernetes.io/proxy-read-timeout>: "600"
[[504 schema changes](https://github.com/airbytehq/airbyte/issues/55690)] If you have any additional reverse proxy (basic auth, API gateway, etc.), check for a timeout variable similar to 
BASIC_AUTH_PROXY_TIMEOUT
and increase it. [[Proxy 504](https://discuss.airbyte.io/t/3305)] - Airbyte server timeouts (Helm values) Some users also set 
HTTP_IDLE_TIMEOUT
and 
READ_TIMEOUT
on the server, though in at least one case this alone did not solve the 60s limit, implying the bottleneck was elsewhere. [[504 schema changes](https://github.com/airbytehq/airbyte/issues/55690)] - Which API call is failing Open your browser dev tools → Network tab, click “Set up source” again, and see which 
/api/v1/...
call returns 504. That will tell you if it’s a 
web_backend/sources/create
, 
sources/check_connection
, or something else. The knowledge sources don’t list the exact endpoint for your case, but this is how similar 504s were diagnosed. 3. Logs to inspect - Ingress / proxy logs to confirm the 504 is generated there. - 
airbyte-server
logs around the time of the request to see if the backend is still working while the proxy times out, as in the other 504 reports. [[504 schema changes](https://github.com/airbytehq/airbyte/issues/55690)] The knowledge sources do not provide a Google‑Ads‑specific 504 fix; they only show that 504s during UI operations are typically due to upstream timeouts (ingress/proxy) that need to be increased. If, after raising those timeouts, you still see a 504, you’d likely need to capture the exact failing endpoint and logs and open a GitHub issue.
The knowledge sources don’t describe this exact Google Ads + OAuth + “Set up source” 504 case, but they do cover very similar 504 / “unknown error” situations in Airbyte, especially on Kubernetes, so I’ll stick to what’s documented. A 504 here means the UI request to the Airbyte backend (usually something like 
/api/v1/sources/check_connection_for_update
or 
/api/v1/sources/create
) is timing out at a proxy/ingress layer before Airbyte finishes responding. This pattern appears in multiple places: - 504 / “An unknown error occurred (HTTP 504)” when refreshing schema or creating a new source (Facebook Marketing) – the UI shows a generic unknown error, while the underlying issue is that the operation takes too long and the gateway times out. [[FB schema 504](https://github.com/airbytehq/airbyte/issues/53132)] - 504 / 502 timeouts in front of Airbyte when using Nginx or the basic auth proxy, fixed or mitigated by increasing proxy timeouts. [[Nginx 504](https://discuss.airbyte.io/t/3305); [Proxy timeout env](https://github.com/airbytehq/airbyte/issues/55690)] On Kubernetes / Helm, the most common causes and mitigations in the docs/issues are: 1. Ingress / proxy timeout too low If you’re fronting Airbyte with Nginx (Ingress controller or external proxy), the default 60s timeout is often too short for “Set up source” / “Check connection” calls. Examples: - Nginx ingress with 600s timeouts configured via annotations to avoid 504s: [[Ingress 504 config](https://github.com/airbytehq/airbyte/issues/55690)]
Copy code
yaml      metadata:        annotations:          <http://nginx.ingress.kubernetes.io/proxy-connect-timeout|nginx.ingress.kubernetes.io/proxy-connect-timeout>: "600"          <http://nginx.ingress.kubernetes.io/proxy-send-timeout|nginx.ingress.kubernetes.io/proxy-send-timeout>: "600"          <http://nginx.ingress.kubernetes.io/proxy-read-timeout|nginx.ingress.kubernetes.io/proxy-read-timeout>: "600"
- For the built‑in basic auth proxy, increasing 
BASIC_AUTH_PROXY_TIMEOUT
is suggested to avoid 504s. [[Proxy timeout env](https://discuss.airbyte.io/t/3305)] If your Helm deployment is behind Nginx or another proxy, you likely need to raise these timeouts so the “Set up source” call can complete. 2. Underlying job or platform slowness / health Several Kubernetes posts show that when any source/destination/connection operation fails with 5xx/504 and “unknown error”, it can indicate an unhealthy deployment (Temporal not reachable, server under‑resourced, etc.). [[K8s check issues](https://discuss.airbyte.io/t/594); [504 on connection](https://discuss.airbyte.io/t/376)] Recommended checks from those threads: - Confirm all core pods (
server
, 
worker
, 
scheduler
, 
temporal
) are healthy and can talk to each other. - Look at airbyte-server logs around the time you click “Set up source” to see if the request is actually completing or failing internally. - Check the job pod that runs the Google Ads check (a pod named like 
source-google-ads-check-...
or similar) to see if it’s hanging or failing. 3. Google Ads–specific platform issues There is an open issue where Google Ads “Check connection” succeeds at the connector level but the platform fails afterward with a 422 when trying to update the source (
updateSource
), even though the connector exits with code 0. [[Google Ads 422](https://github.com/airbytehq/airbyte/issues/60900)] Your 504 is different (timeout vs 422), but it shows that Google Ads + OSS + K8s can hit platform‑side problems after auth/check. If your proxy timeout is high enough and you still see failures, this might be a related platform bug. --- Concrete next steps, based on the docs/issues: 1. Increase proxy/ingress timeouts (if you use Nginx or similar), e.g.:
Copy code
yaml    metadata:      annotations:        <http://nginx.ingress.kubernetes.io/proxy-connect-timeout|nginx.ingress.kubernetes.io/proxy-connect-timeout>: "600"        <http://nginx.ingress.kubernetes.io/proxy-send-timeout|nginx.ingress.kubernetes.io/proxy-send-timeout>: "600"        <http://nginx.ingress.kubernetes.io/proxy-read-timeout|nginx.ingress.kubernetes.io/proxy-read-timeout>: "600"
[[Ingress 504 config](https://github.com/airbytehq/airbyte/issues/55690)] Or, if you’re using the built‑in basic auth proxy, set 
BASIC_AUTH_PROXY_TIMEOUT=600
(or higher) as suggested. [[Proxy timeout env](https://discuss.airbyte.io/t/3305)] 2. Check logs to see what’s actually happening: - 
airbyte-server
logs at the time you click “Set up source”. - The Google Ads check/setup job pod logs (in the 
default
or 
airbyte
namespace, depending on your install). 3. If timeouts persist even with higher proxy limits: - Capture the failing HTTP call from the browser Network tab (URL, status, response body). - Combine that with the server logs and open/update a GitHub issue, referencing that you’re on K8s/Helm and seeing a 504 on “Set up source” for Google Ads, similar to the existing Google Ads platform issue. [[Google Ads 422](https://github.com/airbytehq/airbyte/issues/60900)] The knowledge sources don’t provide a confirmed, Google‑Ads‑specific fix for this 504, but they strongly indicate it’s either a proxy timeout or a slow/blocked backend operation, with proxy timeout increases being the first thing to try.
k
@kapa.ai I was able to get it to add when only using one account in the filter, seems like it is taking to long to read the data sources. would adding. env_vars: HTTP_IDLE_TIMEOUT: 1800s READ_TIMEOUT: 1800s help
k
A message from kapa.ai
Yes, increasing those timeouts is a documented way to address long‑running source operations. The Airbyte docs explicitly recommend raising 
HTTP_IDLE_TIMEOUT
and 
READ_TIMEOUT
on the server when schema discovery or similar one‑time operations run for a long time and hit the default timeout. Example configuration (Helm values) from the docs:
Copy code
yaml server:   extraEnv:     - name: HTTP_IDLE_TIMEOUT       value: 20m     - name: READ_TIMEOUT       value: 30m
[[Scaling timeouts](https://docs.airbyte.com/platform/enterprise-setup/scaling-airbyte#schema-discovery-timeouts)] Your proposed values:
Copy code
yaml env_vars:   HTTP_IDLE_TIMEOUT: 1800s   READ_TIMEOUT: 1800s
are equivalent to 30 minutes, which is in line with (or higher than) the documented examples (20–30 minutes). So: - Yes, increasing these timeouts on the Airbyte server can help if the “Set up source” / discovery step is simply taking too long when multiple accounts are selected. - You still need to ensure any ingress / proxy in front of Airbyte also has sufficiently high timeouts; otherwise, the proxy may still 504 before the server timeouts are reached. The docs don’t give exact values for your stack, but similar 504 issues were traced to ingress timeouts rather than Airbyte itself. [[Review 504](https://github.com/airbytehq/airbyte/issues/55690)] So raising 
HTTP_IDLE_TIMEOUT
and 
READ_TIMEOUT
is a good and documented step; just be aware that it may not be sufficient if an upstream proxy is still enforcing a shorter timeout.
k
@kapa.ai The link in your documentation is missing for V1 helm values file. Can you find this for me?
k
A message from kapa.ai
You’re right that the docs page shows 
loading...
for the V1 values, but it does link to the actual file in GitHub. On the Values.yaml reference page, under “Helm chart V1”, there is a link labeled “See full example on GitHub” that points to: - 
charts/airbyte/values.yaml
in the 
airbyte-platform
repo (Helm chart V1) [[Values reference](https://docs.airbyte.com/platform/deploying-airbyte/values)] Concretely, the link target is:
Copy code
text <https://github.com/airbytehq/airbyte-platform/blob/main/charts/airbyte/values.yaml>
Use that file as the V1 Helm 
values.yaml
reference.
k
@kapa.ai if hosting in kubernetes, how would I connect to the api
k
A message from kapa.ai
To call the Airbyte API from outside your Kubernetes cluster, you need to expose the 
airbyte-server
service via ingress and then use that URL in your API calls. 1. Expose Airbyte via Ingress If you’re using the Helm chart, you can enable ingress in 
values.yaml
so that your cluster exposes a hostname (e.g. 
<http://airbyte.example.com|airbyte.example.com>
) that routes to `airbyte-server`:
Copy code
yaml ingress:   enabled: true   className: "nginx"  # or "alb", etc.   annotations: {}   hosts:     - host: <http://airbyte.example.com|airbyte.example.com>  # replace with your domain       paths:         - path: /           pathType: Prefix           backend: server  # routes to airbyte-server (UI and API)         - path: /connector-builder           pathType: Prefix           backend: connector-builder-server
With this configuration, 
<https://airbyte.example.com>
(or your domain) will serve both the UI and the API. [[Helm ingress](https://docs.airbyte.com/platform/deploying-airbyte/integrations/ingress#option-1-use-airbytes-helm-chart)] If you prefer to create your own ingress resource (e.g. with AWS ALB), you can define it manually and route to the 
airbyte-server
service on port 8001, as in:
Copy code
yaml apiVersion: <http://networking.k8s.io/v1|networking.k8s.io/v1> kind: Ingress metadata:   name: airbyte-ingress   annotations:     <http://kubernetes.io/ingress.class|kubernetes.io/ingress.class>: "alb" spec:   rules:     - host: <http://airbyte.example.com|airbyte.example.com>       http:         paths:           - backend:               service:                 name: airbyte-airbyte-server-svc                 port:                   number: 8001             path: /             pathType: Prefix
[[ALB ingress example](https://docs.airbyte.com/platform/1.8/deploying-airbyte/integrations/ingress)] 2. Obtain an access token Once the deployment is reachable (e.g. 
<https://airbyte.example.com>
), configure API access: - In the Airbyte UI, go to Settings → Account → Applications, create an application, and get a 
client_id
and 
client_secret
. [[Configuring API access](https://docs.airbyte.com/platform/1.8/using-airbyte/configuring-api-access)] - Request an access token from your Airbyte URL:
Copy code
http POST <https://airbyte.example.com/api/v1/applications/token> Content-Type: application/json  {   "client_id": "<your_client_id>",   "client_secret": "<your_client_secret>" }
The response will contain an 
access_token
(valid for 3 minutes). [[Configuring API access](https://docs.airbyte.com/platform/1.8/using-airbyte/configuring-api-access)] 3. Call the API Use that token as a Bearer token when calling any API endpoint, for example:
Copy code
http GET <https://airbyte.example.com/api/public/v1/workspaces> Authorization: Bearer <access_token>
[[Configuring API access](https://docs.airbyte.com/platform/1.8/using-airbyte/configuring-api-access)] If your ingress URL is different, always replace 
<https://airbyte.example.com>
with the hostname you configured.
Open in Slack
PreviousNext
Powered by