LinkedIn Pages to Snowflake: How to Move Your Data

Moving LinkedIn Pages into Snowflake lets you set organic social performance against everything it might be influencing. Follower growth and post engagement are interesting on their own and considerably more useful beside pipeline, hiring and campaign spend.

This guide covers the managed path with Airbyte. Two things shape the build: getting access involves a write-capable scope and a human who can verify your app, and most of what arrives describes the present rather than the past.

LinkedIn Pages to Snowflake at a glance:

Why move data from LinkedIn Pages to Snowflake?

Two situations account for most of these pipelines.

The first is joining organic reach to outcomes. Whether posts preceded inbound enquiries, whether follower growth tracks hiring interest, whether organic and paid move together: all need social data beside commercial data under one set of controls.

The second is keeping a record that LinkedIn's own interface does not present at length. If you want that data in a warehouse on another platform, LinkedIn Pages to BigQuery covers the same ground with different cost mechanics.

What do you need before you start?

Four things, and two of them depend on other people:

A LinkedIn app, verified by a page administrator. You generate a verification URL and somebody who administers your company page has to complete it. The LinkedIn Pages source documentation walks through the sequence.

Scopes that include organization administration. Retrieving reporting data requires a permission that also permits managing your pages, which is worth raising with whoever approves access rather than discovering during a review.

Your organization identifier, from the page URL. A source covers one page, so a group with several company pages needs a source for each and a view to bring them together.

Snowflake objects and a note about credential expiry. A warehouse, database, schema and a role that can create tables, plus a reminder in somebody's calendar for when the tokens run out.

If your Snowflake account restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the network policy before you begin.

How do you build a LinkedIn Pages to Snowflake pipeline in Airbyte?

Step 1: Start the access request early

Create the app, generate the verification URL and get it to your page administrator before doing anything else, because this step waits on somebody who does not work for your data team. Depending on the access your organisation has with LinkedIn, an application review may be involved too. Everything else here takes an afternoon; this is the part that can take a week.

Step 2: Configure the LinkedIn Pages source

Click Sources in the left navigation, then New Source, and select LinkedIn Pages, following adding a source. Supply the organization identifier and either an access token or your client credentials with a refresh token. The second arrangement lasts considerably longer and is worth the extra setup.

Step 3: Configure the Snowflake destination

Click Destinations, then New Destination, and select Snowflake, following adding a destination. Supply the account identifier, warehouse, database, schema and role. This is a small dataset, so the smallest warehouse is ample and nothing about sizing is interesting here.

Step 4: Create the connection and choose append

Click Connections, then New connection, select your streams and a sync mode. The time bound statistics streams support incremental; the rest describe the present, so accumulating rather than overwriting is what gives you a trend later.

Then put the token expiry date somewhere findable, because that is how this pipeline usually ends.

Why does reading reports need an admin scope?

Because LinkedIn bundles reporting access into a permission that also allows managing pages. Retrieving follower and share statistics requires organization administration rights alongside the social read scope, so a pipeline that only ever reads needs a credential capable of rather more than reading.

That is worth raising deliberately rather than quietly accepting, because it is exactly the sort of thing a security review asks about later. The honest framing is that the platform offers no narrower option, so the containment has to come from how you handle the credential rather than from what it permits.

The app verification step compounds it, since somebody who administers your company page must complete a verification you generate. That is a dependency on another team rather than a technical obstacle, and it is the reason this pipeline takes longer to start than its configuration suggests. Ask early and explain what the scope covers while you are asking.

What history do you actually get?

Less than you would expect, which is why the sync mode matters. Organization lookup, total follower count and the main statistics streams describe your page as it is now, so a sync overwriting them leaves you permanently current and permanently without a trend.

The time bound variants of follower and share statistics are the exception, offering incremental sync over a period, and they are the ones to prefer where a choice exists. For everything else, appending a copy on each run is what turns a series of snapshots into something you can plot, and the dataset is small enough that doing so costs nothing.

So build two views as usual: one selecting the latest extraction for current reporting, and one across the accumulated copies for growth over time. If you run several company pages, put the organisation identifier in a union view so somebody can compare them, and remember that a page added later starts its history on the day you started collecting.

Frequently asked questions

Why do I need a write scope to read statistics?

LinkedIn bundles reporting access into an organization administration permission, so there is no narrower read-only option for this data.

Who has to verify the app?

An administrator of your company page. You generate a verification URL and they complete it, so start that request before the rest of the setup.

The pipeline stopped authenticating.

Tokens expire, access tokens sooner than refresh tokens. Using client credentials with a refresh token lasts longer than a pasted access token.

Can one source cover several company pages?

No. The organization identifier covers one page, so several pages need several sources and a union view naming each.

Can I do this without writing code?

The pipeline, yes, once access is granted. The views over accumulated snapshots are short SQL and they are what gives you a trend.

Get your LinkedIn Pages data into Snowflake

Start the app verification early, because it waits on a page administrator and everything else here is quick. Raise the admin scope deliberately, since reading reports requires a permission that also manages pages and there is no narrower option. Then prefer the time bound statistics streams, append the rest so snapshots become a trend, and put the token expiry somewhere findable.

Airbyte's connector catalog includes 600+ pre-built connectors, so organic reach can be measured beside what it produced. For the same source into another warehouse, see LinkedIn Pages to BigQuery, and for attribution data into the same destination, Appsflyer to Snowflake.

Start syncing now →