Connecting OpenClaw with LinkedIn: A Practical Guide

LinkedIn is an obvious target for teams who want an AI assistant that can research prospects, monitor company pages, or pull post analytics into Slack. If you're running OpenClaw and wondering how to connect it to LinkedIn, this guide walks through what's actually involved — the steps, the API limitations, and the significant walls you'll encounter. Spoiler: it's harder than it looks.

How OpenClaw Integrations Work

OpenClaw is a self-hosted AI assistant that runs on your own server — typically an EC2 instance — and connects to Slack. It uses Claude under the hood to process requests. Out of the box, OpenClaw doesn't ship with pre-built connections to third-party tools. Instead, integrations are built using the skills system: markdown files in ~/.openclaw/skills/ that give Claude instructions for a particular domain, combined with HTTP tool calls to any API you expose to it.

In practice, adding a real integration means: getting API credentials from the third-party service, building or configuring a small proxy/endpoint that OpenClaw can call, and writing a skill file that tells Claude how to use it. For some tools this is an afternoon of work. For others — like LinkedIn — it's considerably more involved.

Connecting OpenClaw with LinkedIn: Step by Step

Step 1: Create a LinkedIn Developer Account and App

Start at developer.linkedin.com. You'll need a LinkedIn account and, importantly, a LinkedIn Company Page — new apps must be associated with one. Create a new app, fill in the required details, and you'll receive a Client ID and Client Secret.

At this point, your app has essentially no useful permissions. LinkedIn's default access is limited to "Sign In with LinkedIn using OpenID Connect" — which lets users authenticate with their LinkedIn identity but gives you almost nothing beyond their name and email address. To do anything meaningful, you need to apply for additional products.

Step 2: Apply for the API Products You Actually Need

LinkedIn structures its API access around "Products" — bundles of permissions you apply for separately. The ones relevant to an OpenClaw integration are:

• Share on LinkedIn: Lets your app post content on behalf of a user or organization page. Available to most developers, though it still requires an application.
• Marketing Developer Platform: Required for advertising data, Campaign Manager access, and page analytics. This is a formal application process with a business justification review. Approval typically takes 1–4 weeks and is not guaranteed.
• LinkedIn Pages API: For reading and managing company page content. Also requires a separate application.

To apply, go to your app's "Products" tab in the developer portal and request access to what you need. For the Marketing Developer Platform in particular, you'll be asked to describe your use case, your company, and how you'll use the data. LinkedIn evaluates these and can reject applications that don't fit their partner criteria.

If you need to read a user's connections, feed, or detailed activity — that's not available at all through the public API, regardless of what products you apply for.

Step 3: Implement the OAuth 2.0 Authorization Flow

LinkedIn uses standard OAuth 2.0 with an authorization code flow. Your server needs to:

1. Redirect users to LinkedIn's auth endpoint with your Client ID and the scopes you've been granted
2. Handle the callback and exchange the authorization code for an access token
3. Store the access token securely — and the refresh token if you requested the offline_access scope

LinkedIn access tokens expire after 60 days. Refresh tokens (if granted) last up to a year. You'll need a background process on your EC2 instance that handles token refresh before expiry, or any LinkedIn calls will silently fail when the token expires.

For an OpenClaw integration, you'll likely want to store tokens per-user or for a shared service account, depending on what data you're querying. A shared service account (a LinkedIn member whose credentials are used by the integration) is simpler but has its own risks — if that account gets flagged or suspended, the integration breaks.

Step 4: Build a LinkedIn API Proxy Service

OpenClaw's skill system works by giving Claude instructions and, optionally, HTTP endpoints to call. OpenClaw doesn't natively manage OAuth tokens for third-party services, so you need a small intermediary service — a proxy — that:

• Stores the LinkedIn OAuth tokens your integration obtained
• Exposes simple HTTP endpoints (e.g., GET /linkedin/page-analytics, POST /linkedin/post) that OpenClaw can call
• Translates those calls into properly authenticated LinkedIn API requests

This is typically a small Node.js or Python service running alongside OpenClaw on your EC2 instance (or on a separate server). You'll need to handle token refresh within this service, manage errors, and keep it running and updated as LinkedIn's API evolves.

A minimal implementation might take a day or two for a competent developer. A robust one with proper error handling, token management, and rate limit awareness is a week or more of work.

Step 5: Write the OpenClaw Skill File

Once your proxy is running, create a skill file at ~/.openclaw/skills/linkedin.md on your OpenClaw server. This is a markdown document that tells Claude what LinkedIn data is available and how to query it via your proxy.

For example:

# LinkedIn

You have access to LinkedIn data via the proxy at http://localhost:3001.

Available endpoints:
- GET /linkedin/page-analytics?days=7 — returns page follower count, post impressions, engagement rate
- GET /linkedin/recent-posts?limit=10 — returns the last N posts with engagement metrics
- POST /linkedin/create-post — body: { text: string } — posts to the company page

When asked about LinkedIn performance, call the analytics endpoint first, then summarise the results naturally.

Claude will use these instructions when it determines a LinkedIn question is being asked. The quality of your skill file significantly affects how well the integration works in practice.

Step 6: Test Thoroughly in a Staging Environment

Before relying on this integration for anything important, test it end-to-end:

• Verify token refresh works correctly (you can simulate expiry by manually invalidating a token)
• Test rate limit handling — what happens when you hit LinkedIn's limits?
• Check error messages surface meaningfully in Slack rather than silently failing
• Test with the actual scopes you've been granted, not just in dev mode

LinkedIn's sandbox environment is limited, so most testing has to happen against the real API with real data. Be careful not to accidentally post to your company page during testing.

Challenges and Caveats

LinkedIn Has One of the Most Closed APIs in the Industry

LinkedIn shut down its public API in 2015 and has progressively restricted access since then. What's available to standard developers today is a fraction of what it once was. Most of the data that would actually be useful — reading a user's feed, querying connections, accessing detailed profile data for people outside your network — is simply not available via the API, regardless of what products you apply for. If you're imagining an integration that lets your Slack bot research any LinkedIn profile on demand, that's not achievable through the official API.

API Access is Not Guaranteed

Applying for products like the Marketing Developer Platform doesn't mean you'll get access. LinkedIn reviews applications based on business justification and intended use. Agencies, small startups, and individual developers often find their applications rejected or left in review indefinitely. Even if approved, the scopes granted may be narrower than what you requested. Build your integration plan around what you know you have access to, not what you hope to get.

Rate Limits Are Strict and Per-Member

LinkedIn's rate limits are applied per-member (i.e., per OAuth token) per day. For a Marketing API application, you might be limited to a few hundred calls per day per token. If your integration is querying data on behalf of multiple users, or polling frequently for updates, you'll hit these limits quickly. There's no straightforward way to increase them without moving to a higher-tier partner arrangement, which requires further application and approval.

No Webhooks for Most Events

LinkedIn's webhook support is extremely limited and only available to certain Marketing API partners. For most events — new posts, engagement changes, follower changes — there is no push notification mechanism. This means your integration has to poll, which consumes your rate limit budget and introduces latency. A follower spike or viral post might not surface in Slack until your next scheduled poll.

The Terms of Service Are Unambiguous About Scraping

LinkedIn's User Agreement explicitly prohibits scraping, automated data collection, or using unofficial means to access data on the platform. If you're tempted to skip the API complexity by using a browser automation tool or an unofficial scraping library, be aware that LinkedIn actively detects and blocks this — and accounts found doing it can be suspended without warning. Any integration with OpenClaw must go through the official API.

This Is a Lot of Infrastructure to Maintain

What you're building here isn't a simple API key configuration — it's a custom service (the proxy), a background token refresh job, a skill file, and all the error handling and monitoring that goes with it. Every LinkedIn API update that changes endpoints or deprecates scopes requires you to update your proxy. Every OpenClaw update might affect how skills are loaded. You're taking on meaningful ongoing engineering work for what might seem like a simple integration.

Related Guides

• Connecting OpenClaw with Twitter X: A Practical Guide
• Connecting OpenClaw with Hubspot: A Practical Guide
• Connecting OpenClaw with Salesforce: A Practical Guide

Need the model-flexible version? See: How to Connect LinkedIn to OpenClaw: Setup, Models, and Workflow Guide.