@kapa.ai I have a snapchat connection running daily incremental append but i see 2 days lag in data. For eg for the stream adsquads_stats_daily i see the records having start time 2026-06-26T040000+00:00 and end time 2026-06-27T040000+00:00 on 2026-06-29 2 am et

Snapchat Marketing — 2-Day Data Lag in adsquads_stats_daily The lag you're observing is a known behavior with the Snapchat Marketing connector, and there are a couple of contributing factors documented: 1. UTC Timezone Mismatch / Lookback Window Version 1.5.29 (released 2026-02-24) added a

lookback_window: P2D

specifically to mitigate a UTC timezone mismatch issue. [changelog] This means the connector intentionally looks back 2 days from the cursor to catch records that may have been affected by timezone differences between your local time and UTC. The data you're seeing (records up to 2026-06-26/27 when it's 2026-06-29 02:00 ET) is consistent with this behavior. 2. end_datetime Defaulting to Midnight There is an open issue (#54139) reporting that when

end_date

is not specified,

end_datetime

defaults to midnight (000000.000Z) of the current day rather than end-of-day (235959.999Z). This means records updated after midnight UTC on the current day are excluded from the sync window. [GitHub issue] Version 1.5.13 (released 2025-07-02) included a fix titled "Fix end datetime to include today," which partially addressed this. [changelog] What You're Likely Seeing • At 2026-06-29 02:00 ET (= 07:00 UTC), the sync window ends at the current UTC date boundary. • The

P2D

lookback window shifts the effective start back by 2 days, so the latest partition covers roughly 2026-06-26 → 2026-06-27. • This is expected behavior given the lookback window introduced in v1.5.29. Recommendations 1. Ensure you're on the latest connector version (1.5.40 as of 2026-06-23). [changelog] 2. Set an explicit

end_date

in your connection config if you want to control the sync window boundary precisely. 3. Be aware that the 2-day lag is partly intentional (lookback window) to handle timezone mismatches — the data for the most recent 2 days will be re-synced on subsequent runs to catch late-arriving updates. If the lag is larger than expected or records are still missing after the lookback window, the open issue #54139 is worth tracking, as it has not been fully resolved for all affected streams. 👍 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 i am using this version 1.5.27 and i dont want to set enddate as i wil be pulling daily

Running v1.5.27 Without an End Date You're on v1.5.27, which is several versions behind the current release (v1.5.40). This is relevant because some key fixes were released after v1.5.27: [changelog] Your Specific Problem On v1.5.27, without an

end_date

set, the

end_datetime

defaults to midnight (000000.000Z) of the current day. This means: • Any records updated after midnight UTC on the current day are excluded from the sync window. • This is the root cause of the data lag you're seeing, as described in the open GitHub issue. [GitHub issue] Recommendation Upgrade to v1.5.40 (latest). The fixes introduced in v1.5.29 and v1.5.13 (which were not in your current version) directly address the lag issue you're experiencing for daily incremental syncs without an end date. [changelog] After upgrading: • The

P2D

lookback window will help catch timezone-related misses. • The end datetime fix will ensure today's records are included in the sync window. > ⚠️ Note that even after upgrading, a ~1–2 day lag may still appear on any given run due to the intentional lookback window, but subsequent daily syncs will backfill those records correctly. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements

@kapa.ai currenlty i have this Swipe Up Attribution Window 28 day View Attribution Window 1 day

Your current attribution window settings are actually the correct defaults for the Snapchat Marketing connector: • Swipe Up Attribution Window:

28_DAY

✅ (this is the default) • View Attribution Window:

1_DAY

✅ (this is the default) [setup guide] These settings look fine and are unlikely to be contributing to the 2-day data lag you're seeing. The lag issue is more related to the connector version (v1.5.27) and the

end_datetime

defaulting to midnight bug, as discussed previously. The available options for each window are: No changes needed here — the priority fix remains upgrading to v1.5.40. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements

@kapa.ai 1.5.29 2026-02-24 73634 fix(source-snapchat-marketing): add lookback_window P2D to mitigate UTC timezone mismatch (AI-Triage PR) i see a fix made in this version. so before this version the issue is there?

Yes, that's correct. The

lookback_window: P2D

fix was introduced in v1.5.29 (2026-02-24). [changelog] Since you're on v1.5.27, you are running a version before this fix was applied, which means: • There is no lookback window to compensate for the UTC timezone mismatch. • Combined with the

end_datetime

defaulting to midnight bug (also not fixed in v1.5.27), your daily syncs are likely missing records that fall near day boundaries due to timezone differences. This directly explains the 2-day lag you're observing in

adsquads_stats_daily

— the connector on v1.5.27 simply doesn't have the safeguards that were added in later versions to handle this. Bottom Line Upgrading to v1.5.40 would apply both fixes: 1. The

P2D

lookback window (v1.5.29) to handle UTC timezone mismatch. 2. The end datetime fix (v1.5.13, backported) to include today's records. This should significantly reduce or eliminate the data lag you're seeing on daily incremental syncs without an

end_date

. [changelog] 👍 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 since today is 29 and i have data till 26th, if i updgrade the version and run will i get the 27 28 data now

The knowledge sources do not contain enough information to give a fully confident answer on exactly what data will be backfilled when you upgrade and re-run. However, based on what is documented: What the P2D Lookback Window Does The lookback window subtracts 2 days from the last cursor value before starting the next sync. [lookback window docs] So after upgrading to v1.5.40 and running: • The connector will look back 2 days from your current cursor position (which is at June 26th). • This means it should re-sync from around June 24th onwards, which would include June 27th and 28th data. However, There Are Caveats • The lookback window is designed to catch missed records near day boundaries, not to do a full historical backfill. • If your cursor state is already saved at June 26th, the sync will start from

June 26 - 2 days = June 24th

and move forward — so June 27 and 28 should be picked up. To Be Safe If after upgrading and running the sync you still don't see June 27/28 data, you may need to: 1. Manually reset the stream state for

adsquads_stats_daily

to a date before June 27th via the Airbyte UI. 2. Re-run the sync to force a backfill of the missing dates. I'd recommend upgrading first, running a sync, and verifying whether June 27/28 data appears before taking any further action. 👍 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 for testing purpose in a different workspace i updated by connector version and created a new source , and ran the stream

adsquads_stats_daily with full refresh and start date 20 th june 2026, sync completed and it showed 0 records, i created a new connection

This is concerning and is actually a known bug that has been reported by other users. The GitHub issue #54139 specifically mentions getting 0 records on successful syncs even after trying different

start_date

settings. [GitHub issue] Likely Cause Even on the latest version, the

end_datetime

defaulting to midnight (000000.000Z) when no

end_date

is specified can cause 0 records to be returned. The issue is: • The sync window ends at

2026-06-29T00:00:00.000Z

(midnight UTC). • Since you're running at 2 AM ET = 6 AM UTC, the entire current day's window is effectively collapsed, potentially returning no records. Things to Try 1. Set an explicit

end_date

(e.g.,

2026-06-28

) temporarily to test if records come through — this would confirm the

end_datetime

bug is the culprit. 2. Check the sync logs for the actual API request being made — specifically what

start_time

and

end_time

parameters are being sent to the Snapchat API. Important Note The knowledge sources do not contain enough information to confirm whether v1.5.40 fully resolves the 0 records issue for

adsquads_stats_daily

specifically. The GitHub issue #54139 remains open, meaning this may still be an unresolved bug even on the latest version. I'd recommend opening a support ticket referencing issue #54139 if setting an explicit

end_date

confirms the bug is still present on v1.5.40. 👍 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 but atleast i need to get some records from 20th right, today is 29 th

You're absolutely right — with a

start_date

of June 20th and today being June 29th, you should be getting 9 days worth of records regardless of any

end_datetime

issue. Getting 0 records is not expected behavior. This Points to a Deeper Problem The knowledge sources do not contain enough information to pinpoint the exact root cause of 0 records in your specific test case. However, based on the open GitHub issue #54139, other users have reported the exact same symptom — successful sync with 0 records — even after: • Setting an earlier

start_date

✅ • Setting an explicit

end_date

✅ • Upgrading connector versions ✅ [GitHub issue] Recommended Next Steps 1. Check the sync logs in detail — look for the actual API request parameters (

start_time

,

end_time

) being sent to Snapchat to confirm what the connector is actually requesting. 2. Verify your credentials have access to the ad accounts/squads in the test workspace. 3. Try a different stream (e.g.,

AdSquads

or

Campaigns

) to check if the issue is specific to stats streams or affects all streams. 4. Raise a GitHub issue or check if your case matches #54139 and add a comment there, as this appears to be an unresolved bug. 👍 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 2026-06-29 145637 source INFO MemoryMonitor instantiated with critical threshold: 95%, anon share of usage threshold: 85%, high-pressure threshold: 90%, check interval: 5000 messages (tightens to 100 under high pressure). 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source WARN Parent state handling is not supported for CartesianProductStreamSlicer. 2026-06-29 145637 source INFO Starting syncing 2026-06-29 145637 source INFO Marking stream adaccounts_stats_daily as STARTED 2026-06-29 145637 source INFO Syncing stream: adaccounts_stats_daily 2026-06-29 145637 source INFO Read 0 records from adaccounts_stats_daily stream 2026-06-29 145637 source INFO Marking stream adaccounts_stats_daily as STOPPED 2026-06-29 145637 source INFO Finished syncing adaccounts_stats_daily 2026-06-29 145637 source INFO Finished syncing

The logs reveal a critical clue — the stream reads 0 records almost instantly (all within the same second

14:56:37

). This means the connector isn't even making an API call to Snapchat — it's returning 0 records before any network request is attempted. Root Cause: CartesianProductStreamSlicer Warning The repeated warnings:

WARN Parent state handling is not supported for CartesianProductStreamSlicer.

This is the key issue. The

adsquads_stats_daily

(and

adaccounts_stats_daily

) streams use a

SubstreamPartitionRouter

— they are child streams that depend on a parent stream (e.g.,

AdAccounts

). [contributing docs] This warning indicates that the parent stream is returning no data, so the child stats stream has no partitions to iterate over and immediately returns 0 records. What to Check 1. Does your test workspace have Ad Accounts configured? ◦ The stats streams require valid Ad Account IDs to partition against. ◦ If the authenticated account has no accessible ad accounts, all child streams will return 0 records. 1. Try syncing the

AdAccounts

stream first in your test connection — if that also returns 0 records, the issue is with credentials/permissions, not the stats stream itself. 2. Check your Organization IDs / Ad Account IDs settings in the source config — if these are set incorrectly or point to accounts the OAuth token can't access, all child streams will be empty. This is likely a credentials or permissions issue in your test workspace, not a connector bug. 👍 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 always returns 0 records in the latest version

The knowledge sources do not contain enough information to confirm whether the latest version (v1.5.40) always returns 0 records as a general bug. However, based on what we've analyzed from your logs, the most likely cause is not a connector version bug but rather the parent stream returning no data, which cascades to 0 records in all child stats streams. What the Logs Tell Us

WARN Parent state handling is not supported for CartesianProductStreamSlicer.
INFO Read 0 records from adaccounts_stats_daily stream

The sync completes in under 1 second with no API calls made — this strongly points to the parent

AdAccounts

stream being empty, not a stats stream bug. Most Likely Causes 1. OAuth token in the test workspace doesn't have access to the same Ad Accounts as your production workspace. 2. Organization IDs or Ad Account IDs are misconfigured in the test source. 3. The authenticated Snapchat user in the test workspace has different permissions. Recommended Verification Steps 1. In your test workspace, sync the

adaccounts

stream alone — if it returns 0 records, the issue is confirmed to be credentials/permissions. 2. Compare the OAuth credentials used in your test workspace vs your production workspace. 3. Check if Organization IDs are explicitly set in the test source config and match your production setup. This would explain why your production connection on v1.5.27 does return data while the test connection on v1.5.40 returns 0 records — same connector bug, different root cause. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

same credentials i used @kapa.ai

The knowledge sources do not contain enough information to definitively explain why v1.5.40 returns 0 records with the same credentials that work on v1.5.27. However, this is a significant finding — same credentials, same data, different connector version = different results. This strongly suggests a regression introduced in a version between 1.5.27 and 1.5.40. What Changed Between v1.5.27 and v1.5.40 Looking at the changelog, the most relevant changes were: [changelog] Recommended Actions 1. Try v1.5.29 specifically — this is the first version with the lookback window fix. If it returns records, the regression was introduced after this version. 2. Report this as a bug on the open GitHub issue #54139 with your findings — same credentials working on v1.5.27 but returning 0 records on v1.5.40 is critical evidence of a regression. 3. Stay on v1.5.27 for now in production until the issue is investigated, to avoid disrupting your existing data pipeline. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements

@kapa.ai i tried in 1.5.29 getting 0 records Active Streams StatusStream nameLatest sync in Syncedads 0 loadeda few seconds ago Syncedadsquads 0 loadeda few seconds ago Syncedadsquads_stats_daily 0 loadeda few seconds ago

The knowledge sources do not contain enough information to fully explain why v1.5.29 also returns 0 records with the same credentials. However, notice that even

ads

and

adsquads

(non-stats streams) are returning 0 records. These are simpler streams that don't depend on stats partitioning. This is a very important clue. This Rules Out the Stats Stream Bug Since

ads

and

adsquads

themselves return 0 records, the issue is not related to: • The

end_datetime

midnight bug • The

CartesianProductStreamSlicer

/ parent stream issue • The lookback window Most Likely Cause Something is different between your test workspace source config and your production source config, even if the credentials are the same. Things to double-check: 1. Start Date format — verify it's entered correctly (e.g.,

2026-06-20

) in the test source. 2. OAuth token — even with the same client ID/secret, the OAuth flow may have generated a different token with different scopes in the test workspace. Try re-authenticating. 3. Snapchat App permissions — check if the Snapchat app has

snapchat-marketing-api

scope granted. Immediate Next Step Can you check the full sync logs for the

ads

stream in v1.5.29? Specifically look for: • Any API requests being made • Any

ERROR

or

400/401/403

HTTP responses This will help confirm whether it's an authentication issue vs a connector bug. 👍 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 when i am giving some start date it is giving 0 records but if i dont give start date it is pulling rcords

This is a very useful finding! The behavior you're describing — 0 records with a start date, but records returned without a start date — points to a date parsing or format mismatch issue with how the connector handles the

start_date

config field. What's Likely Happening When you provide a

start_date

(e.g.,

2026-06-20

), the connector may be: • Misinterpreting the date format • Setting the

start_datetime

incorrectly, causing the sync window to be invalid • Resulting in an empty date range that returns 0 records This is consistent with what was reported in a similar issue for another connector: [GitHub issue] > "Airbyte doesn't seem to be reading that start date field correctly — it might be a mismatch on the exact data type / a failure of translation to what the system is expecting." Things to Verify 1. Confirm the date format — the connector expects

start_date

strictly in

YYYY-MM-DD

format (e.g.,

2026-06-20

). [setup guide] 2. Check the sync logs when providing a start date — look for what

start_time

value is actually being sent in the API request. 3. Try an older start date like

2026-01-01

to rule out any edge case with recent dates. Recommendation Since the knowledge sources do not contain enough information to confirm this as a documented bug specific to

start_date

on the Snapchat Marketing connector, I'd strongly recommend: • Adding a comment to the open GitHub issue #54139 with this finding — it's a critical data point that records appear when no

start_date

is given but not when one is provided. • For now, leave

start_date

blank in your production connection if it's returning records correctly without it. 👍 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 i dont want to keep start date as blank as it will pull lot of records

That's a completely valid concern. Unfortunately, the knowledge sources do not contain enough information to provide a definitive workaround for this specific bug where providing a

start_date

causes 0 records. What We Know So Far This Looks Like a Regression The fact that v1.5.27 works with a

start_date

but v1.5.29+ doesn't is strong evidence of a regression introduced in v1.5.29 — likely related to the

lookback_window P2D

change or how

start_datetime

is now being calculated. [changelog] Recommended Actions 1. Stay on v1.5.27 in production — it works with

start_date

and returns records. 2. Report this as a bug on GitHub issue #54139 with these exact findings:This is critical evidence the Airbyte team needs to fix the regression. ◦ v1.5.27 works with

start_date

◦ v1.5.29+ returns 0 records with

start_date

◦ Removing

start_date

returns records on v1.5.29+ 1. On v1.5.27, to manage the volume of records pulled without upgrading, consider setting an explicit

end_date

temporarily to limit the sync window while the bug is being fixed. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements

In snapchat why does the spend column became multiplied by 1000 times @kapa.ai

The knowledge sources do not contain enough information to fully explain why the

spend

column values appear multiplied by 1000 in your data. However, based on what is documented: This Is Expected — Snapchat Uses Micro-Currency The Snapchat Marketing API returns spend values in micro-currency format, meaning the actual value is the raw number divided by 1,000,000 (not 1,000). [GitHub issue] For example: This is also confirmed by the field descriptions in the connector: >

daily_budget_micro

— Daily budget in micro-currency [reference docs] The same applies to related fields: •

spend

•

coupon_used_local

•

coupon_used_usd

What You Need to Do To get the actual spend value in your BI tool, divide the

spend

column by 1,000,000:

SELECT spend / 1000000 AS actual_spend
FROM adsquads_stats_daily

This is standard behavior from the Snapchat API and is not a connector bug — the connector passes through the raw micro-currency values as returned by the API. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements

@kapa.ai for old data i had it coming correctly did it change recently is the issue from snapchat side or airbyte

The knowledge sources do not contain enough information to confirm whether there was a recent change — either from Snapchat's API side or from Airbyte's connector side — that caused the

spend

column values to change in magnitude. What the Knowledge Sources Tell Us The only relevant change to the

spend

field in the changelog is: [changelog] This suggests the

spend

field has had issues before, but there is no documented change in the knowledge sources that explains a sudden multiplication of spend values for previously correct data. Recommended Next Steps 1. Check when exactly the values changed — identify the exact date the spend values started looking inflated. This will help correlate it with a specific connector version update. 2. Compare connector versions — check which connector version was running when the data was correct vs when it changed. 3. Check Snapchat's API changelog directly at developers.snap.com/api/marketing-api/Ads-API to see if they made any changes to how spend is returned. 4. Raise this with Airbyte support — since you're seeing a change in previously correct data, this warrants a support ticket with the exact dates and version numbers. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements