Core architecture difference
REST API: record-driven
Returns survey response records scoped to a customer or order.
Represents the totality of the customer experience.
Deduplicates across the entire customer survey engagement lifecycle.
UI: event-driven
Hyper-focused on specific time periods.
Optimized for app performance.
Deduplicates only within the selected time frame.
Timestamp meanings
created_at: First time engagement with the survey.updated_at: Most recent record or engagement during a time period.
Why discrepancies occur
Submissions
β Align exactly between API and UI. A submission event happens only once.
Views and responses
β οΈ UI consistently over-reports when using narrow date ranges.
Multiple engagement events, such as viewing a thank you page across multiple days or purchases, are counted separately in the UI.
The API collapses these into a single record per customer.
Example scenario
A large brand pulls data daily using created_at. This approach misses the full engagement picture if a customer:
Makes multiple purchases.
Views the thank you page on different days.
Recommendations for better alignment
Use wider date ranges so records have time to settle and update.
Query by
updated_atinstead ofcreated_atwhen pulling broad data patches.Treat both as accurate. They are measuring slightly different things from the same source of truth.
Bottom line
The REST API and UI charting will never align fully due to their architectural differences (record-driven vs event-driven). Neither is inaccurate. They serve different purposes with the same underlying data.
