@kapa.ai Jira connector get all the ticket for Jiraproduct discovery also?

The knowledge sources do not explicitly mention Jira Product Discovery (formerly Productboard) as a supported project type or entity in the Airbyte Jira connector. Here's what the Airbyte Jira source connector supports for fetching issues: • The Issues stream fetches issues via JQL from

/rest/api/3/search/jql

, filtering by project if configured. [Jira manifest] • The JQL query used is:

updated >= <timestamp> [AND project in (<project_id>)] ORDER BY updated asc

Whether Jira Product Discovery tickets are included depends on: 1. If you leave the projects filter empty — the connector fetches all issues across all projects your credentials have access to. If Jira Product Discovery projects are accessible via the standard Jira REST API (

/rest/api/3/search

), they would be included. 2. If you specify projects — only issues from those specified projects are fetched. However, Jira Product Discovery uses a separate data model and may not expose all its data through the standard Jira REST API v3. The knowledge sources do not confirm whether Product Discovery ideas/tickets are retrievable via the standard issues endpoint. Recommendation: Check whether your Jira Product Discovery items appear when you run a JQL query like

project = <your_product_discovery_project>

in your Jira instance. If they do, the Airbyte connector should be able to sync them. If not, they may not be supported. For the AI agent connector, the same applies — it uses bounded JQL queries to search issues. [Jira agent connector] If you need confirmed support for Jira Product Discovery, I'd recommend opening a GitHub issue with the Airbyte team. 👍 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 my gmail auth is expire do you allow reauth or i need to add again the new connector.

Thinking completed You do not need to create or add a new connector. Airbyte allows you to re-authenticate existing connectors when credentials expire or are revoked [GitHub Issue (closed): [source-s3]]. To re-authenticate your connection: 1. In Airbyte, navigate to your existing source. 2. Go to the Settings tab [Tutorials Chat with your data warehouse without writing SQL>]. 3. Click Re-authenticate (or update your credentials / re-run the OAuth consent flow) [GitHub Issue (closed): [source-s3]; Documentation Integrations > Sources > Greenhouse>]. 4. Save your changes. (Note: If you are using an Airbyte AI Agent connector, you can re-authenticate by clicking the pencil icon on the row or clicking Edit on the connector detail page to re-launch the authentication module [Ai-agents Interfaces > Ui > Add a connector>].) 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

Failure in source: Exhausted available request attempts. Please see logs for more details. Exception: Gmail returned a per-user or per-project quota saturation 403 (rateLimitExceeded / userRateLimitExceeded). Honouring

Retry-After

and retrying — the sync will resume once Gmail’s rolling quota window frees up. @kapa.ai suddenly hitting this anyone else facing this issue.

Thinking completed This error occurs when your sync saturates the quota limits enforced by the Gmail API. Why this happens The Gmail API enforces two simultaneous quota limits measured in quota units [Documentation Integrations > Sources > Gmail>]: • Per project rate limit: 1,200,000 quota units per minute [Documentation Integrations > Sources > Gmail>] • Per user rate limit: 15,000 quota units per minute per user [Documentation Integrations > Sources > Gmail>] Each request consumes units (for example,

messages.list

and

messages.get

cost 5 units each, while

threads.list

and

threads.get

cost 10 units each) [Documentation Integrations > Sources > Gmail>]. Because substreams like

messages_details

and

threads_details

issue a separate

get

request for every parent record, high-volume mailboxes can exhaust quota units very quickly [Documentation Integrations > Sources > Gmail>]. The Airbyte Gmail connector is designed to catch these quota-saturation

403

errors (

rateLimitExceeded

or

userRateLimitExceeded

), treat them as rate limits, and apply exponential backoff while respecting the

Retry-After

header [Airbyte-integrations Connectors > Source-gmail > manifest.yaml>]. However, if the quota remains saturated and retries are repeatedly exhausted, the sync will eventually fail. How to resolve it 1. Lower concurrent workers: In your Gmail source configuration in Airbyte, lower the Number of concurrent workers setting. Reducing concurrency decreases the number of simultaneous API requests and prevents hitting the per-user or per-project rate limit [Documentation Integrations > Sources > Gmail>]. 2. Only sync required streams: If you do not need full message bodies or headers, avoid syncing

messages_details

or

threads_details

, as these substreams issue individual API calls per message/thread and drive up quota usage significantly [Documentation Integrations > Sources > Gmail>; Documentation Integrations > Sources > Gmail>]. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

what shoud the concurent workker setting to avoid 403 @kapa.ai

Thinking completed The knowledge sources do not specify an exact number that guarantees avoiding

403

rate-limit errors, as quota consumption depends on your mailbox volume and which streams you sync [Documentation Integrations > Sources > Gmail>]. However, they provide the following guidance: • The default value is

5

workers [Documentation Integrations > Sources > Gmail>]. • The connector allows setting the Number of concurrent workers between

2

and

10

[Documentation Integrations > Sources > Gmail > Setup guide>]. • If you are experiencing frequent rate-limit warnings or quota saturation errors, you should reduce this value toward the lowest allowed setting of

2

[Documentation Integrations > Sources > Gmail > Setup guide>; Documentation Integrations > Sources > Gmail>]. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

“UnauthorizedServiceAccountError(‘Unable to connect with provided Service Account credentials. Make sure the

sevice account credentials

provided are valid.’)” @kapa.ai issue fror google search console.

Thinking completed This error indicates that Google Search Console cannot validate or authenticate using the provided service account credentials [Forum Post: Google Search Console - Service Account Key Authentication Failure]. To fix this issue, verify the following configuration and permission steps: 1. Check Service Account Permissions on the Property • Even if the service account key is valid in Google Cloud, the service account email must be explicitly added as a user to your Google Search Console property [Documentation Integrations > Sources > Google Search Console>]. • In the Google Search Console UI, have a property owner go to Settings > Users and permissions, and add the service account email (usually looks like

<name>@<project-id>.iam.gserviceaccount.com

) as a user with at least Viewer or Full permissions [Documentation Integrations > Sources > Google Search Console>; Documentation Integrations > Sources > Google Search Console>]. 2. Verify Domain-Wide Delegation (if using an Admin Email) • In the connector configuration for Service Account authentication, Airbyte requires an Admin Email alongside the key [Airbyte-integrations Connectors > Source-google-search-console > manifest.yaml>; Documentation Integrations > Sources > Google Search Console>]. • If you are using service account impersonation across a Google Workspace domain, your Google Workspace super admin must configure domain-wide delegation in the Google Workspace Admin console [Documentation Integrations > Sources > Google Search Console>]. • Make sure the service account is authorized with the following OAuth scope [Documentation Integrations > Sources > Google Search Console>]https//www.googleapis.com/auth/webmasters.readonly 3. Confirm the Google Search Console API is Enabled • If you are running Airbyte Open Source, ensure that the Google Search Console API is enabled inside your Google Cloud project credentials console [Documentation Integrations > Sources > Google Search Console>]. 4. Verify the JSON Key Format • Ensure the entire content of the downloaded

.json

key file is copied directly into the Service Account JSON Key field without alterations or missing brackets [Documentation Integrations > Sources > Google Search Console>]. It should begin with

{"type": "service_account", ...}

[Documentation Integrations > Sources > Google Search Console>]. 5. Check the Website URL Property format • The connection test queries the

sites

endpoint for every URL listed in your configuration [Documentation Integrations > Sources > Google Search Console>]. Make sure the format matches what appears in Google Search Console: ◦ URL-prefix properties must include the protocol and trailing slash (e.g.,

https://example.com/

) [Airbyte-integrations Connectors > Source-google-search-console > manifest.yaml>; Documentation Integrations > Sources > Google Search Console>]. ◦ Domain properties must include the

sc-domain:

prefix (e.g.,

sc-domain:example.com

) [Airbyte-integrations Connectors > Source-google-search-console > manifest.yaml>; Documentation Integrations > Sources > Google Search Console>]. 👍 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 Configuration check failed “UnauthorizedServiceAccountError(‘Unable to connect with provided Service Account credentials. Make sure the

sevice account credentials

provided are valid.’)” getting this on google search console how to add the correction permission. what i admin email

Thinking completed What is the "Admin Email"? In the Google Search Console connector configuration, the Admin Email is the email address of the user who has permissions to access the Google Workspace Admin APIs and whose account is being impersonated by the service account [manifest.yaml; Google Search Console setup guide]. Because service accounts use domain-wide delegation to access data across an organization via impersonation, the connector requires this email alongside your JSON key to authenticate requests [Google Search Console setup guide]. How to Add the Correct Permissions To resolve the

UnauthorizedServiceAccountError

, complete the following permission and setup steps: 1. Enable Domain-Wide Delegation in Google Workspace Only a super admin of your Google Workspace domain can enable domain-wide delegation [Google Search Console setup guide]: 1. Go to your Google Workspace admin console. 2. Enable domain-wide delegation for your service account's client ID [Google Search Console setup guide]. 3. Add and authorize the following OAuth scope for the service account [Google Search Console setup guide]https//www.googleapis.com/auth/webmasters.readonly 2. Grant Permissions to the Service Account in Google Cloud 1. Go to the Service Accounts page in the Google Cloud Console [Google Search Console setup guide]. 2. Under Service account permissions, ensure the service account is assigned a role such as Viewer [Google Search Console setup guide]. 3. Add the Account to the Search Console Property The property must be accessible to the authenticated account [Google Search Console troubleshooting]: 1. Open Google Search Console. 2. Ensure a property owner adds either the Google user account (the Admin Email) or the service account email as a user with at least Viewer (or Full User) permissions on the property [Google Search Console setup guide; Google Search Console troubleshooting]. 4. Enable the Google Search Console API Ensure that the Google Search Console API is enabled in your Google Cloud project credentials console [Google Search Console setup guide]. 👍 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 how to add aws secret manager for keys saving what to udapte in values.yaml in airyte 1.6.2 version

Thinking completed To configure AWS Secrets Manager for storing connector credentials in Airbyte, you need to configure the

global.secretsManager

section in your

values.yaml

file and ensure the required Kubernetes secret exists. Step 1: Create the Kubernetes Secret Before updating

values.yaml

, ensure you have created a Kubernetes secret containing your AWS credentials (if using credential-based authentication). By default, Airbyte expects the secret to be named

airbyte-config-secrets

[Creating Kubernetes Secrets; Secret Management Values]:

apiVersion: v1
kind: Secret
metadata:
  name: airbyte-config-secrets
type: Opaque
stringData:
  aws-secret-manager-access-key-id: <your-aws-access-key-id>
  aws-secret-manager-secret-access-key: <your-aws-secret-access-key>

[Secret Management] Apply it to your cluster in the Airbyte namespace:

kubectl apply -f secrets.yaml -n airbyte

[Creating Kubernetes Secrets] Step 2: Update values.yaml In your

values.yaml

file, add or update the

global.secretsManager

section:

global:
  secretsManager:
    type: AWS_SECRET_MANAGER
    secretName: "airbyte-config-secrets" # Name of your Kubernetes secret
    awsSecretManager:
      region: <aws-region> # e.g. us-east-1
      authenticationType: credentials # Use "credentials" or "instanceProfile"
      tags: # Optional: tags added to secrets created by Airbyte
        - key: team
          value: deployments
        - key: business-unit
          value: engineering
      kms: "" # Optional: ARN for KMS Decryption if KMS is used

[Secret Management Values] Configuration Options: •

authenticationType

: ◦ Set to

credentials

if you are providing the access keys in the Kubernetes secret [Secret Management Values]. ◦ Set to

instanceProfile

if the underlying compute (such as an EKS node or IAM Role for Service Accounts/IRSA) already has an IAM role attached with permissions to AWS Secrets Manager [AWS Infrastructure; Secret Management Values]. •

kms

: (Optional) Specify the KMS key ARN if you are encrypting/decrypting secrets using AWS KMS [Secret Management Values]. Step 3: Required AWS IAM Permissions Ensure the IAM policy associated with your AWS credentials or role allows Airbyte to manage secrets:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:CreateSecret",
        "secretsmanager:ListSecrets",
        "secretsmanager:DescribeSecret",
        "secretsmanager:TagResource",
        "secretsmanager:UpdateSecret"
      ],
      "Resource": [
        "*"
      ],
      "Condition": {
        "ForAllValues:StringEquals": {
          "secretsmanager:ResourceTag/AirbyteManaged": "true"
        }
      }
    }
  ]
}

[External Secret Management; AWS Infrastructure] > Important Note: Modifying the configuration of connector secret storage causes all existing connectors to fail; they will need to be recreated so that they read from the new secret manager [Secret Management Values]. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

{ “Version”: “2012-10-17", “Statement”: [ { “Effect”: “Allow”, “Action”: [ “secretsmanager:GetSecretValue”, “secretsmanager:CreateSecret”, “secretsmanager:ListSecrets”, “secretsmanager:DescribeSecret”, “secretsmanager:TagResource”, “secretsmanager:UpdateSecret” ], “Resource”: [ “*” ], “Condition”: { “ForAllValuesStringEquals” { “secretsmanagerResourceTag/AirbyteManaged” “true” } } } ] } @kapa.ai how will it know “secretsmanagerResourceTag/AirbyteManaged” “true”

Thinking completed Airbyte automatically applies this tag to the secrets it creates in AWS Secrets Manager [Verification Steps]. When Airbyte manages secrets in AWS Secrets Manager: 1. Whenever Airbyte writes or creates a secret, it adds the tag

AirbyteManaged=true

to the resource [External Secret Management; Verification Steps]. 2. AWS evaluates the IAM policy's

Condition

block (

secretsmanager:ResourceTag/AirbyteManaged: "true"

) against the tags present on the secret. Because the secret carries the

AirbyteManaged=true

tag, the request satisfies the condition and AWS permits the action [External Secret Management]. 3. Any secrets that do not have this tag will be denied access by AWS, ensuring Airbyte can only access and modify its own managed secrets [External Secret Management; Best Practices]. You can confirm this behavior during setup: after Airbyte creates a secret, you can inspect it in the AWS Secrets Manager console to verify that the tag

AirbyteManaged=true

is attached to it [Verification Steps]. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

“Internal Server Error: No declarative manifest image version found in database for major version 6” @kapa.ai

Thinking completed This error occurs when you try to publish, save, or test a declarative (Connector Builder) connector that requires a specific major version of the Connector Development Kit (CDK), but your Airbyte configuration database does not have an entry for that major version in the

declarative_manifest_image_version

table [Issue #84928]. Cause 1. Seed data lag: Airbyte ships with baked-in manifest image versions that only cover older major versions (typically up through major 4) [Issue #84928]. 2. DockerHub rate limiting: A background job (

DeclarativeSourcesUpdater

) runs periodically to fetch the newest CDK versions and SHAs from DockerHub to populate the

declarative_manifest_image_version

table [Issue #84928; Issue #84928]. If this job hits DockerHub rate limits (e.g., HTTP

403

errors during pagination), it fails and discards the fetched versions, preventing the table from ever updating [Issue #84928; Issue #84928]. 3. When you attempt to publish a connector declaring CDK major version 6, the lookup in the database fails and returns an internal server error [Issue #84928]. Workaround You can resolve this immediately by manually inserting the missing major version into the

declarative_manifest_image_version

table in your Airbyte config database [Issue #84928]. 1. Connect to your Airbyte database (e.g., using

psql

). 2. Run an

INSERT

statement providing an image version and SHA for major version 6 [Issue #84928]:

INSERT INTO declarative_manifest_image_version 
  (major_version, image_version, created_at, updated_at, image_sha)
VALUES 
  (6, '<image_version>', NOW(), NOW(), 'sha256:<image_digest>');

_(Replace

<image_version>

and

<image_digest>

with a valid published version tag and SHA from the

airbyte/source-declarative-manifest

repository)._ [Issue #84928] Once inserted, publishing or saving the connector should work immediately without needing a container or service restart [Issue #84928]. 👍 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 we added email connector and hitting limit ay fix for that yet 15000 unit we are hitting.

Based on the previous conversation context, you are hitting the 15,000 quota units per minute per-user rate limit on the Gmail connector. Here is what is currently available to mitigate this: Why You Are Hitting the Limit The per-user limit of 15,000 quota units per minute is consumed quickly because [Documentation Integrations > Sources > Gmail>]: •

messages.list

and

messages.get

= 5 units each •

threads.list

and

threads.get

= 10 units each • Substreams like

messages_details

and

threads_details

issue one

get

call per parent record, so a large mailbox exhausts quota very fast [Documentation Integrations > Sources > Gmail>] Available Fixes Right Now 1. Lower Concurrent Workers to Minimum (2) This is the most direct lever available in the connector configuration [Documentation Integrations > Sources > Gmail > Setup guide>]: • Go to your Gmail source settings in Airbyte • Set Number of concurrent workers to

2

(minimum allowed) • Save and re-run the sync 2. Disable Unused Substreams If you do not need full message content, disable these high-cost streams in your connection [Documentation Integrations > Sources > Gmail>]: •

messages_details

— 5 units per message •

threads_details

— 10 units per thread Only enable the streams you actually need. 3. Set a Start Date Setting a Start date limits the volume of records the connector processes, reducing the total number of API calls made per sync [Documentation Integrations > Sources > Gmail > Setup guide>]:

2024-01-01T00:00:00Z

4. Increase Quota in Google Cloud Console The 15,000 units/min/user limit is a Google-enforced quota. You can request a quota increase directly from the Google Cloud Console under APIs & Services > Gmail API > Quotas. This is outside Airbyte's control but is a valid long-term fix. Important Note The knowledge sources do not mention any planned connector-level fix specifically targeting the 15,000 per-user quota limit beyond the above mitigations [Documentation Integrations > Sources > Gmail>]. The connector already retries

429

and quota-saturation

403

errors with exponential backoff, but if the quota remains consistently saturated, retries will eventually be exhausted [Documentation Integrations > Sources > Gmail>]. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.