> For the complete documentation index, see [llms.txt](https://docs.coupler.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.coupler.io/troubleshooting/why-api-data-is-different-from-what-users-see-in-the-ui.md).

# Why API data is different from what users see in the UI

Coupler.io imports data from your source app through its API. If the numbers in your Coupler.io dataset, dashboard, or report don't match what you see in the source app's interface, it's usually not a bug on either side.

The reason is that the API and the UI represent different layers of the same data. Coupler.io gets exactly what the source app's API returns. But the interface you're used to looking at in that app applies its own filters, calculations, permissions, time zone logic, and formatting before showing you anything. The result is two views of the same data that can look different.

This article explains the most common reasons for the mismatch. For step-by-step resolution of specific sources, see our dedicated troubleshooting page on data mismatch.

{% content-ref url="/pages/kSjpXKKt9UqUn02ENVM5" %}
[Data doesn't match](/troubleshooting/data-doesnt-match-between-the-source-coupler-preview-and-destination.md)
{% endcontent-ref %}

{% hint style="info" %}
Note: If the mismatch is between your Coupler.io preview (the "Data sets" step) and your destination file, that's a different issue — usually related to destination settings, sheet selection, or column mapping.
{% endhint %}

### The source UI applies additional filters

The API may return all available records, while the source app's UI shows only a filtered subset. Common filters the UI applies silently:

* Only active items (hiding deleted, archived, or paused records)
* Only data from the selected date range
* Only visible columns
* Only records available to the current user's role
* Only non-archived items

If you're seeing more records in Coupler.io than you expected, the API is likely returning the unfiltered set.

> Example: **Google Analytics 4**
>
> Adding a dimension to a GA4 API query can change metric totals, because only events containing that dimension get included. The UI report may apply a different default dimension set, so the same date range produces different numbers.
>
> Example: **Facebook Ads**
>
> The Facebook Ads API returns stats for deleted and archived entities when you query at the parent level (e.g., ad set). So Coupler.io results may include data from ads that are no longer visible in Ads Manager. If you use any filtering in Coupler.io, status filtering is applied by default to return only ACTIVE objects. See [Facebook Ads common issues](https://docs.coupler.io/sources/category/ppc/facebook-ads/common-issues#data-discrepancies) for details on how to handle this.

### The source UI uses aggregated or calculated values

The API often returns raw events or individual objects. The source app's UI takes those and calculates derived metrics like conversion rate, revenue totals, engagement rate, cost per result, attributed conversions, or averages.

So a dashboard might show "conversion rate: 3.2%" while the API gives you raw conversion events and impression counts. The numbers come from the same source, but the UI did math on top of them.

> Example: **Shopify**
>
> The Order API exposes raw order-level data: line items, refunds, quantities, taxes, discounts. Shopify's UI sales reports apply additional reporting logic on top of that. Rebuilding the same totals from API data means reconstructing that logic from orders, refunds, gift cards, and removed quantities.
>
> Example: **HubSpot**
>
> HubSpot supports calculated properties, including custom equations based on other property values. The UI displays the calculated result, while the API may return the underlying stored property in a different format or with different update timing.
>
> Example: **Google Ads**
>
> Coupler.io returns data at the lowest entity level based on the metrics and dimensions you select. If you select Campaign name, you get a campaign-level report. Adding Ad set name switches to ad-set-level data. This can produce different totals than an aggregated campaign report in the Google Ads UI. See [Google Ads common issues](https://docs.coupler.io/sources/category/ppc/google-ads/common-issues#data-discrepancies) for more on entity aggregation.

### Data freshness differs

The API and the source UI don't always update at the same time. The UI might use cached data, delayed reporting tables, or pre-aggregated datasets. The API might return fresher raw data. Or the reverse: some UIs refresh faster than certain API endpoints.

If you see a temporary mismatch that resolves after a few hours, freshness lag is the most likely cause.

> Example: **LinkedIn Ads**
>
> Some demographic metrics in LinkedIn's reporting API are delayed 12–24 hours, and video watch metrics can be delayed up to 48 hours. The UI may show partial or estimated data sooner.
>
> Example: **Google Ads**
>
> Performance data, especially conversion data, may not be available instantly. Some metrics are processed with delays, and certain reports are calculated once per day rather than continuously. Google publishes a [Data Freshness Guide](https://support.google.com/google-ads/answer/2544985) that explains expected delays by metric type.

### Time zones are handled differently

This is one of the most common causes of mismatched data.

The API typically returns timestamps in UTC. The source app's UI shows data in the account's local time zone. A record timestamped at 11 PM UTC on March 31 shows up as April 1 in UTC+2. That single record can land in different days, weeks, or months depending on which system you're looking at.

When comparing Coupler.io data to the source app's UI, always check which time zone each side is using.

> Example: **Facebook Ads**
>
> The "Split data by period" setting in Coupler.io (Daily, Weekly, Monthly, Totals) must match the time aggregation you're viewing in Ads Manager. If Ads Manager shows monthly data and Coupler.io is set to daily, the totals may not align when you sum them up due to time zone boundary differences. See [Facebook Ads common issues](https://docs.coupler.io/sources/category/ppc/facebook-ads/common-issues#data-discrepancies) for how to match these settings.

### Attribution logic differs

For marketing and analytics platforms (Google Ads, Facebook Ads, HubSpot, etc.), the source UI often applies attribution settings behind the scenes: attribution window, conversion model, click vs. view attribution, campaign-level attribution, and delayed conversion reporting.

The API may require you to specify these settings explicitly in your request parameters. If you don't, you get default attribution logic, which may not match what the source UI is configured to use.

> Example: **Meta Ads**
>
> Meta's own Insights API documentation states that API defaults differ from Ads Manager. To reproduce what Ads Manager shows, API requests need explicit parameters for attribution windows, breakdowns, date presets, and action report time. In Coupler.io, if nothing is selected in advanced settings, a 7-day click attribution window is used by default. If your Ads Manager uses a different window, the conversion numbers won't match. See [Facebook Ads common issues](https://docs.coupler.io/sources/category/ppc/facebook-ads/common-issues#data-discrepancies) for how to align attribution windows.
>
> Example: **Google Ads**
>
> Imported conversions are reported on the original click's impression date, not the import date. A conversion you imported today might show up under a date from weeks ago in the API export, while the UI may present it differently.

### Permissions affect visible data

A user with a restricted role may see limited data in the source UI. API credentials can have broader, narrower, or simply different access. This causes missing records, hidden fields, or different totals depending on which set of credentials is pulling the data.

If your Coupler.io import shows fewer (or more) records than the source UI, check whether the API token's permission scope matches the UI user's access level.

### API endpoints represent different data models

The source UI often combines multiple internal sources into one screen. A single UI table might show object details, related entities, calculated fields, historical values, and status labels pulled from different backend services.

The API endpoint may expose only one slice of that combined view. Reproducing the full UI picture can require multiple API requests stitched together.

> Example: **GA4 / BigQuery**
>
> The GA4 UI and Data API group low-volume dimension values into an "(other)" row, while the BigQuery export contains more granular event-level data. A report built from BigQuery can show different totals or breakdowns than the GA4 UI because BigQuery is closer to raw event data, while the reporting layer applies aggregation and grouping rules.
>
> Example: **Google Ads**
>
> Custom columns created in Google Ads are not supported by the Google Ads API and cannot be retrieved in reports. If you're comparing a UI view that includes custom columns, those metrics won't appear in Coupler.io data.

### Deleted, archived, or updated records are treated differently

Some APIs return deleted or archived records by default unless you explicitly filter them out. Most source UIs hide them automatically.

Edited records can also diverge: the UI typically shows the latest version, while some API endpoints return historical or raw values. If your Coupler.io export includes records you can't find in the source UI, check whether they're deleted, archived, or superseded.

> Example: **Google Ads**
>
> If a campaign, ad, or keyword has no reported performance metrics for the chosen period, it won't appear in API results. The API does not return null or empty values. So your Coupler.io report may be missing entries that show as zero in the Google Ads UI.

### Naming and formatting differ

The source UI shows friendly names, rounded numbers, localized dates, and formatted currencies. The API returns the raw version:

* IDs instead of display names
* Raw timestamps instead of "March 15, 2026"
* Micros instead of standard currency values (e.g., 1500000 instead of $1.50)
* Unrounded decimal values
* Technical status codes instead of labels

This doesn't mean the data is wrong. It means the API gives you the machine-readable version, and the source UI gives you the human-readable one.

### API limitations or bugs

Sometimes the difference genuinely is a platform issue: endpoint limitations, undocumented behavior, reporting delays, or actual bugs on the source side.

> Example: **LinkedIn Ads**
>
> The reporting API returns only the top 100 professional demographic values per creative per day and drops values with fewer than 3 events as a privacy threshold. These are documented API-side limitations that don't exist in the UI.
>
> Example: **GA4**
>
> API reports can be affected by sampling and thresholding that the UI may handle differently or flag more visibly. The GA4 UI shows a sampling indicator; the API response includes metadata about whether results were sampled, but it's easy to miss.

### What to check when Coupler.io data doesn't match the source UI

When you spot a mismatch, work through these checks:

* Date range and time zone. Confirm that the Coupler.io source settings use the same reporting period and time zone as the source UI.
* Filters and segments. Match all source UI filters, including hidden defaults like status filters, campaign selections, and breakdowns. Check your Coupler.io advanced filter settings as well.
* Metric definition. Check whether the source UI metric is raw, calculated, estimated, sampled, or attributed. A "revenue" number in the UI might include logic the API doesn't apply automatically.
* Attribution settings. For ad platforms, compare click/view windows, conversion date logic (click date vs. conversion date), and attribution model. Make sure Coupler.io advanced settings match your source app's configuration.
* Freshness delay. Avoid comparing very recent data before the platform has finished processing it. Wait at least 24–48 hours for platforms with known reporting delays.
* Permissions. Confirm that the API token used in Coupler.io and the source UI user have access to the same accounts, fields, and restricted metrics.
* Data model and aggregation level. Check whether the source UI combines several endpoints or entities that the API exposes separately. Verify that the entity level in Coupler.io (campaign, ad set, ad) matches the report level in the source UI.
* Rounding and formatting. Compare raw values before rounding, currency formatting, or percentage calculation. A 0.01 difference in a rate can look like a real discrepancy when it's just a rounding artifact.
* Deleted and archived entities. Check whether your source UI hides deleted or archived items that the API still returns.

In most cases, the mismatch has a specific, identifiable cause. Coupler.io gives you what the source app's API returns — raw or endpoint-specific data. The source app's UI gives you filtered, transformed, and formatted data. Neither is wrong. They're showing different layers of the same information.

\ <br>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.coupler.io/troubleshooting/why-api-data-is-different-from-what-users-see-in-the-ui.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.