Source connector

LinkedIn Ads connector

LinkedIn Ads integration for databases, warehouses and BI tools

B2B advertising metrics for pipeline and attribution reporting. Datrise captures LinkedIn Ads entities such as B2B campaign metrics, spend, clicks, leads, and audience performance, then lands normalized and typed models for warehouse reporting, attribution, and AI workflows.

The LinkedIn Marketing API — Ad Analytics (versioned REST, e.g. 202608) authenticates with OAuth 2.0, incremental runs key on dateRange (query window per pull), and LinkedIn Ads caps calls at 45,000,000 metric values (fields requested x records returned) per rolling 5-minute window on the `adAnalytics` endpoint; exceeding it returns HTTP 429 TOO_MANY_REQUESTS.

Of the 5 objects, 3 sync as upserts keyed on the primary key and 2 as append-only streams, so each incremental run moves only what changed since the last watermark. Every object lands in its own table (for example `linkedin_ads_b2b_campaign_metrics`) with a schema derived from the LinkedIn Ads API rather than a flattened CSV, in any of the 43 supported destinations.

Datrise is in early access: pick a destination below to open the LinkedIn Ads pipeline page, and join the waitlist to get the LinkedIn Ads connector (Ads) with guided onboarding.

Incremental syncSchema-aware mapping43 destinations available

What LinkedIn Ads data Datrise extracts

Each object lands in its own typed table. Sync mode is derived from the object: history-style objects append, everything else upserts.

Object	Landing table	Sync mode
B2B campaign metrics	linkedin_ads_b2b_campaign_metrics	Append-only, incremental by timestamp
spend	linkedin_ads_spend	Upsert by primary key, incremental on updated-at
clicks	linkedin_ads_clicks	Append-only, incremental by timestamp
leads	linkedin_ads_leads	Upsert by primary key, incremental on updated-at
audience performance	linkedin_ads_audience_performance	Upsert by primary key, incremental on updated-at

LinkedIn Ads API: setup facts for the connector

Verified against the vendor documentation on 2026-09-02. Unknown values are left blank rather than guessed.

API	LinkedIn Marketing API — Ad Analytics (versioned REST, e.g. 202608)
Authentication	OAuth 2.0 — 3-legged OAuth 2.0 only — LinkedIn does not support the 2-legged client credentials flow for any Marketing/Ads use case; calls need the `r_ads_reporting` scope (plus `r_ads`/`rw_ads` for account and campaign objects) granted by a member holding an Ad Account role.
Pagination	none — The docs state the `adAnalytics` endpoint 'currently does not support pagination' even though responses still include a `paging` object with `start`/`count`/`links`; a single response is capped at 15,000 elements regardless.
Rate limit	45,000,000 metric values (fields requested x records returned) per rolling 5-minute window on the `adAnalytics` endpoint; exceeding it returns HTTP 429 TOO_MANY_REQUESTS
Incremental cursor	dateRange (query window per pull) — Results are pre-aggregated metrics keyed by pivot and `dateRange`, not individual mutable records, so incremental extraction means advancing the requested date window rather than filtering on a last-modified field.
Webhooks	No
Bulk export	No
Deletes detectable	No — the endpoint returns aggregated metrics only; a deleted campaign, creative, or share simply stops accruing new rows rather than being flagged, and analytics for a deleted share must be retrieved by querying the creative URN that sponsored it

Official API reference

What bites when replicating LinkedIn Ads

The `adAnalytics` endpoint enforces a data-throttling ceiling of 45 million metric values (fields requested times records returned) per rolling 5-minute window; exceeding it returns HTTP 429 `TOO_MANY_REQUESTS`.
Despite responses including a `paging` object, the docs explicitly say `adAnalytics` 'currently does not support pagination' and caps any single response at 15,000 elements, so large pulls must be split by narrower `dateRange` windows or extra facets instead of paging.
With `timeGranularity=ALL`, a requested date outside the 6-month daily-retention window is silently rounded to month boundaries, returning whole-month totals instead of the exact range requested.
Professional-demographic metrics (e.g. `MEMBER_JOB_TITLE` pivots) lag 12 to 24 hours behind non-demographic performance metrics, and `videoWatchTime`/`averageVideoWatchTime` can lag up to 48 hours, so a same-day incremental pull under-reports those specific fields.

Compare this against every other documented API