@kapa.ai Configuration check failed 'Limit reached for partners-report' getting issue with appsflyer source

AppsFlyer "Limit reached for partners-report" Error This error occurs when the AppsFlyer API rate limit is hit for aggregate report endpoints (like the partners report). The connector uses the partners report endpoint specifically during its connection check, so if the rate limit is exceeded at that moment, the check itself will fail. What's Happening The

check_connection

method tests connectivity by calling the partners report endpoint:

test_url = f"https://hq1.appsflyer.com/api/agg-data/export/app/{app_id}/partners_report/v5?from={dates}&to={dates}&timezone=UTC"

When the API returns HTTP

403

with a message containing

"Limit reached for "

, the connector detects this as a rate limit condition. [source code] How the Connector Handles Rate Limits For aggregate report endpoints (like partners report), when a

403 Limit reached

response is received: •

should_retry

returns

True

•

backoff_time

returns 60 seconds (waits 1 minute before retrying) However, during the connection check, this retry/backoff logic may not apply, causing the check to surface the raw error message. [source code] Recommended Steps 1. Wait and retry — The aggregate report rate limit resets after a short period (the connector uses a 60-second backoff). Try re-running the connection check after a minute or two. 2. Check your AppsFlyer API quota — Log in to your AppsFlyer dashboard and verify you haven't exceeded your API call quota for the partners report. AppsFlyer enforces per-report, per-app, and per-account quotas. 3. Reduce sync frequency — If you're running frequent syncs, the cumulative API calls may be exhausting your quota. Consider spacing out your syncs. 4. Verify your API token — Ensure you're using a valid API V2 token with admin-level access, as required by the connector. [PR #77580] 5. Check the 90-day start date limitation — Note that there is a known issue where the connector caps all streams at a 90-day window, even for aggregate endpoints that support longer historical pulls. This is a separate bug but worth being aware of. [GitHub Issue #60994] If the error persists after waiting, it's likely an account-level quota issue that needs to be resolved directly with AppsFlyer support. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

connection passed now @kapa.ai

That's great news! The connection check passing confirms the rate limit had cleared. The temporary 60-second backoff the connector uses for aggregate report limits was sufficient in this case. If you encounter the

Limit reached

error again during actual syncs, keep in mind the retry behavior: • Aggregate report limits (like partners report): connector waits 60 seconds before retrying • Raw data report limits: connector waits until midnight UTC before retrying [source code] To minimize hitting rate limits going forward, consider reducing your sync frequency if you're running syncs very often. Let me know if you run into any other issues! 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

but i am facing issue with the sync. the sync runs daily and it works, but from last 2 days it is not working. It is runnin only this step not pulling any records 2026-05-24 103125 destination INFO pool-2-thread-1 i.a.c.i.d.a.b.BufferManager(printQueueInfo):94 [ASYNC QUEUE INFO] Global: max: 445.44 MB, allocated: 10 MB (10.0 MB), %% used: 0.0224495236780081 | State Manager memory usage: Allocated: 10 MB, Used: 0 bytes, percentage Used 0.0 2026-05-24 103125 destination INFO pool-5-thread-1 i.a.c.i.d.a.FlushWorkers(printWorkerInfo):127 [ASYNC WORKER INFO] Pool queue size: 0, Active threads: 0 @kapa.ai

Sync Hanging with No Records Being Pulled The logs you're seeing indicate the destination's async buffer is idle — it's allocated memory but has 0 records in the queue and no active worker threads. This means the destination is waiting for records from the source that never arrive. What the Logs Mean

[ASYNC QUEUE INFO] Global: max: 445.44 MB, allocated: 10 MB, %% used: 0.02
Pool queue size: 0, Active threads: 0

The destination buffer is running but empty — the source (AppsFlyer) is not sending any records to it. Likely Causes This pattern is consistent with a known issue where the source connector quits silently without error when dealing with large volumes of data. There is a reported bug for

source-appsflyer

where streams like

in_app_events

or

organic_in_app_events

quit with no exception or traceback when returning a large number of rows. [GitHub Issue #60998] Additionally, this could also be related to a known GlobalMemoryManager negative accounting bug in the async buffer framework, which can cause syncs to hang indefinitely flushing 0 records. [GitHub Issue #74897] Recommended Steps 1. Check source-side logs — Look at the source container logs specifically to see if the AppsFlyer connector is silently exiting or hitting a rate limit before sending records. 2. Check if data volume increased — Since this started 2 days ago, check if the amount of data being pulled has grown significantly (e.g., more events than usual). 3. Try narrowing the date range — Reduce the sync window temporarily to confirm whether large data volume is the cause. 4. Restart/cancel the sync — Cancel the hanging sync and trigger a fresh one, as the buffer state may be stuck. 5. Check your Airbyte and connector versions — Upgrading to the latest versions of both the connector and Airbyte platform may include fixes for these known issues. Unfortunately, the knowledge sources do not contain a confirmed fix for the silent source exit issue in

source-appsflyer

specifically — the GitHub issue was closed as stale without a resolution. [GitHub Issue #60998] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.