LinkedIn’s OAuth model for the Marketing API requires human re-authentication on a fixed schedule. Unlike Google Ads (service account, non-expiring key) and Meta (long-lived system user tokens with indefinite refresh), LinkedIn access tokens expire after 60 days and refresh tokens expire after 365 days, with no automated alternative.
The Token Hierarchy
LinkedIn OAuth has two token types:
Access tokens expire after 60 days. Every API call you make authenticates with an access token. When it expires, your pipeline stops working.
Refresh tokens expire after 365 days. A refresh token lets you exchange it for a new access token without requiring the user to log in again. Refresh tokens are only available to approved LinkedIn Marketing Developer Platform (MDP) partners — standard API access doesn’t include refresh token support.
The practical consequence: if you have standard API access (not MDP partner status), someone has to log in and re-authenticate every 60 days. No exceptions.
If you have MDP partner status and refresh tokens available, you still hit a hard wall at 365 days. At that point, the refresh token itself expires, and there’s no way to get a new one without interactive authentication. Someone has to open a browser, go through the OAuth flow, and authorize the application again. You cannot automate around this — LinkedIn’s API design explicitly prevents it.
Comparing to Other Platforms
This limitation is worth understanding in context, because it shapes the build-vs-buy decision for LinkedIn pipelines.
Google Ads uses a service account pattern. You create a service account in GCP, grant it access to your Google Ads account, and use a never-expiring service account key to authenticate. Your pipeline runs indefinitely without human intervention. The security model is service-account-centric, not user-centric.
Meta’s system user tokens work similarly. You create a system user in Business Manager, generate a long-lived token, and that token doesn’t expire. You rotate it manually when you choose to, not when Meta forces you to.
LinkedIn has no service account equivalent. Authentication is always tied to a real LinkedIn user who authorized the app via the OAuth flow. When their session expires, the pipeline dies. This is a deliberate design decision on LinkedIn’s part — their terms of service restrict programmatic access to what an authenticated human could see.
Operational Strategy for Custom Pipelines
If you’re committed to a custom pipeline rather than a managed tool, here’s what realistic token management looks like:
Calendar alerts, not code alerts. Set a recurring calendar event for 45 days after each token issuance (not 60, to leave a buffer). This is the reminder to re-authenticate. If you have MDP partner status and a 365-day refresh token, set the calendar event for 330 days. Don’t rely on your pipeline’s error alerting to catch this — by the time alerts fire, you’re already in an outage.
Dashboard monitoring for token age. Store the token issuance timestamp in a small config table in your warehouse. Write a simple monitoring query that alerts when CURRENT_DATE - token_issued_date > 50 (for 60-day access tokens) or > 350 (for 365-day refresh tokens). Attach this to your standard data quality monitoring run so the alert surfaces before the expiry.
Document who does the re-auth. Token refresh requires someone with a LinkedIn account that has access to the ad account. Document which person owns this task and make sure that person doesn’t leave the company without transferring access. This sounds obvious until you get a 2am alert that your LinkedIn pipeline broke because the person who set it up left three months ago and nobody updated the credentials.
Test the re-auth flow before you need it under pressure. Go through the OAuth flow once in a staging environment so you know exactly what steps are required. Doing it for the first time during a production incident at the end of a financial quarter is a bad situation.
When Managed Tools Make More Sense
Fivetran, Airbyte, and similar managed ELT tools handle OAuth through their own partner OAuth flows. When you connect a LinkedIn account to Fivetran, Fivetran manages the token lifecycle on your behalf. Token expiry doesn’t cause a pipeline outage — Fivetran prompts the account owner to re-authenticate through their interface, usually with slack from the expiry deadline.
For teams where LinkedIn Ads is a secondary data source (not the primary focus of the analytics system), the operational overhead of managing OAuth tokens manually is often the decisive argument for a managed connector. The cost of Fivetran is frequently less than the cost of one production outage caused by a forgotten token refresh.
If LinkedIn is a core data source and you’re running a custom pipeline for control reasons (specific demographic pivots, lead form data structures, custom incrementality logic), build the token management infrastructure from day one. Don’t add it later.
MDP Partner Status
If your team or your product involves managing LinkedIn Ads data for multiple clients, you may qualify for MDP partner status, which unlocks refresh tokens and longer-lived access patterns. The bar is higher — LinkedIn vets MDP applications more carefully than standard API access — but the operational benefits are significant for production pipelines at scale.
For most single-company analytics teams building internal reporting, MDP status isn’t the path. The 60-day access token cycle with calendar-based renewal is the realistic operational model. Build for it explicitly rather than hoping you’ll upgrade to refresh tokens later.