Forem: Nicolas Lecocq

Voice-Matching LinkedIn Posts With Claude + 5 Sample Posts

Nicolas Lecocq — Tue, 12 May 2026 15:00:01 +0000

When users sign up for my LinkedIn tool, the first request I get is "make it sound like me." Generic AI output sounds the same across every account, and people can tell. The model writes the way training data writes. To match a specific person's voice, you have to either fine-tune or feed examples in-context. Fine-tuning is expensive, requires hundreds of samples, and locks you into one model. Examples in-context cost nothing extra and work across any frontier model.

Five sample posts is the threshold I have found where Claude (Sonnet 4.6 in my testing) reliably matches sentence rhythm, word choice, opener style, and ending pattern. Three samples is too noisy. Ten samples does not measurably improve over five, and it eats context.

Here is the prompt structure I landed on after a lot of iteration.

The system prompt

You are writing a LinkedIn post in the user's exact voice.

The user's writing style is defined by these five sample posts.
Study them for: sentence length distribution, opener patterns,
word choice, transition style, ending patterns, and any
recurring phrases.

DO NOT copy phrases or sentences verbatim from the samples.
DO match the rhythm, tone, and structural choices.

Sample 1:
[paste full post 1]

Sample 2:
[paste full post 2]

Sample 3:
[paste full post 3]

Sample 4:
[paste full post 4]

Sample 5:
[paste full post 5]

User context:
- Business: [user.businessDescription]
- Audience: [user.targetAudience]
- Tone preference: [user.writingTone]
- Topics to avoid: [user.neverMention]

Write a new LinkedIn post on the topic the user provides.
Match the voice from the samples. The post should feel like
something this user would write today, not a generic AI output.

The exact wording matters less than the structure. Five labeled samples, then context, then the task. Putting the task before the samples weakens voice transfer measurably.

What changed when I used Anthropic's prompt caching

Five sample posts at 200-400 words each is roughly 4,000-8,000 input tokens. Plus the system prompt scaffolding. Plus user context. You are at 10,000 input tokens per request before the user's actual prompt arrives. At standard Claude pricing, that is about $0.03 per generation just for the voice setup.

Anthropic's prompt caching makes the same setup cheap to reuse:

const message = await client.messages.create({
  model: "claude-sonnet-4-6",
  max_tokens: 1024,
  system: [
    {
      type: "text",
      text: voicePrompt, // the structured prompt above
      cache_control: { type: "ephemeral" },
    },
  ],
  messages: [
    { role: "user", content: userTopic },
  ],
});

Mark the system prompt with cache_control: { type: "ephemeral" }. The first request computes the cache. Every subsequent request from the same user reuses it at 10% of the input cost. Cached entries live 5 minutes by default.

For a user generating multiple drafts in a session, the first generation costs full price ($0.03). The next 5-10 inside that 5-minute window cost about $0.003 each. The cost math gets a lot better when you multiply across users.

What "voice match" actually means

When I say Claude "matches voice" with five samples, here is what it actually does well and what it does not:

Does well:

Sentence length distribution. If samples are mostly 8-15 words, output trends 8-15. If samples mix short and long, output mixes.
Opener style. Question openers, story openers, contrarian openers. Picks up the dominant pattern from samples.
Word choice. If you avoid corporate words in samples, output avoids them. If you use technical terms, output uses them.
Closing pattern. Question closer, takeaway closer, no closer. The model picks one consistent with samples.

Does not do well:

Specific anecdotes. The model will not invent your stories. If you want a story-shaped post, you have to give it the story in the prompt.
Inside-baseball references. If your audience knows specific tools, names, or running jokes, the model misses them unless you list them in user context.
Long-form structural patterns. For posts under 300 words, voice transfer is strong. For longer-form (1000+ words), the model's training-data rhythm starts leaking through.

Sample selection matters

Bad sample selection breaks voice match. Three rules I learned from testing:

Use posts the user actually wrote alone. Posts written by ghostwriters or heavily edited by an editor pull voice in the wrong direction.
Pick posts that did well, not random ones. Successful posts represent the user at their best. The model anchors on whatever you feed it, including bad posts.
Vary the post types. One opinion post, one story, one contrarian, one tactical, one personal. Five copies of the same format teaches the model to write that format, not to match the voice.

A user who pastes their five top-performing varied-format posts gets dramatically better output than a user who pastes the first five posts off their profile.

What this replaced

Before voice matching, my generated posts felt like AI output. Generic. Same cadence as every other tool's output. Users would generate, look at it, and rewrite from scratch. Conversion to a paying plan was bad.

After voice matching, generated posts feel like the user's posts. They still need light editing, but the editing is "fix one phrase" not "rewrite from scratch." The conversion math changed because users actually use the output instead of treating it as a starting brainstorm.

The whole feature is twenty lines of code plus the prompt template. It is one of those moments where the AI-product cliché ("the prompt is the product") turns out to be literally true.

Generating LinkedIn Carousels as Multi-Page PDFs With Puppeteer

Nicolas Lecocq — Mon, 11 May 2026 15:00:03 +0000

LinkedIn carousels are not images. They are PDFs, one page per slide, uploaded as a document attachment to the share. LinkedIn's renderer turns each page into a swipeable slide on the feed. This is one of those things that took me three failed uploads to figure out, because the documentation says "carousel" and your mind says "image sequence."

Once you know it is a PDF, the pipeline is straightforward. Render HTML templates to PDF with Puppeteer, upload the PDF to LinkedIn as a document, attach to a share. Here is the working setup.

The HTML template approach

Each slide is a 1080x1350 HTML page. I render them with React on the server, write the HTML to disk, then point Puppeteer at it.

The slide template:

function Slide({ index, total, title, body }: SlideProps) {
  return (
    <html>
      <head>
        <style>{`
          @page { size: 1080px 1350px; margin: 0; }
          html, body { margin: 0; padding: 0; width: 1080px; height: 1350px; }
          .slide {
            width: 1080px; height: 1350px;
            display: flex; flex-direction: column;
            padding: 80px;
            font-family: Inter, system-ui, sans-serif;
          }
        `}</style>
      </head>
      <body>
        <div className="slide">
          <h2 style={{ fontSize: 56, lineHeight: 1.1 }}>{title}</h2>
          <p style={{ fontSize: 28, marginTop: 32 }}>{body}</p>
          <div style={{ marginTop: "auto", fontSize: 18, opacity: 0.5 }}>
            {index + 1} / {total}
          </div>
        </div>
      </body>
    </html>
  );
}

The @page rule is the part that keeps biting people. PDF page size is set in CSS, not in Puppeteer. Set it once per page, omit margins, and your output matches the slide dimensions exactly.

The Puppeteer call

Render each slide's HTML to a separate PDF, then concatenate. This is more reliable than rendering one giant multi-page document because Puppeteer handles single-page renders cleanly and concatenation is fast.

import puppeteer from "puppeteer";
import { PDFDocument } from "pdf-lib";

async function renderCarousel(slides: SlideHtml[]): Promise<Uint8Array> {
  const browser = await puppeteer.launch({ headless: true });
  const pdfBuffers: Uint8Array[] = [];

  for (const slideHtml of slides) {
    const page = await browser.newPage();
    await page.setContent(slideHtml, { waitUntil: "networkidle0" });
    const pdf = await page.pdf({
      width: "1080px",
      height: "1350px",
      printBackground: true,
      preferCSSPageSize: true,
    });
    pdfBuffers.push(pdf);
    await page.close();
  }

  await browser.close();

  // Concatenate into a single PDF
  const merged = await PDFDocument.create();
  for (const buf of pdfBuffers) {
    const single = await PDFDocument.load(buf);
    const [copied] = await merged.copyPages(single, [0]);
    merged.addPage(copied);
  }

  return merged.save();
}

preferCSSPageSize: true is what makes the @page size in your HTML actually apply. Without it, Puppeteer falls back to its default A4 and you get a tiny 1080px image floating in a giant page.

printBackground: true is the difference between "your background colors render" and "your slides come out white because Puppeteer skips background paints by default."

waitUntil: "networkidle0" matters if your slides load fonts or images. Skip it and you race the loader.

Hosting Puppeteer on Vercel

Puppeteer ships with a bundled Chromium. The bundle is roughly 170MB, which exceeds Vercel's serverless function size limit. You have three options:

Use @sparticuz/chromium, which is a slimmed Chromium specifically for serverless. Combined with puppeteer-core, the function fits under the 50MB limit on Vercel.
Run the rendering on a separate machine (a small Fly.io or Render container) and call it from Vercel.
Use a managed PDF API like Browserless or PDFShift.

I went with option 1 for cost, option 2 for reliability when traffic gets uneven. Both work. Option 3 is fastest to set up and the most expensive at scale.

Setup with @sparticuz/chromium:

import puppeteer from "puppeteer-core";
import chromium from "@sparticuz/chromium";

const browser = await puppeteer.launch({
  args: chromium.args,
  executablePath: await chromium.executablePath(),
  headless: chromium.headless,
});

Uploading to LinkedIn

Once you have the PDF, the upload flow is similar to images. POST to /rest/documents?action=initializeUpload, PUT the PDF bytes to the returned upload URL, attach the document URN to your share.

const init = await fetch(
  "https://api.linkedin.com/rest/documents?action=initializeUpload",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${token}`,
      "LinkedIn-Version": "202401",
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ initializeUploadRequest: { owner: authorUrn } }),
  }
);
const { value } = await init.json();

await fetch(value.uploadUrl, { method: "PUT", body: pdfBytes });

// Attach value.document URN to your UGC share's media field

LinkedIn caps document size at 100MB and 300 pages. For carousels, you will usually be in the 1-5MB and 5-15 page range, so the cap rarely matters.

What the user sees

The PDF you upload becomes a swipeable carousel in the feed. Each page is one slide. LinkedIn's renderer adds the page count overlay automatically, but I include my own 1/N indicator at the bottom of each slide because the LinkedIn one is positioned poorly on mobile.

Once the upload pipeline is in place, generating 10-slide carousels takes about 4-6 seconds end to end. Most of that is Puppeteer cold start. Subsequent runs in the same warm function drop to 2-3 seconds.

The whole thing is one of those "nobody told me it was a PDF" gotchas. Once you know, the implementation is shorter than the figuring-out.

BYOK Architecture: How I Made My LinkedIn AI Tool 96% Cheaper Than Competitors

Nicolas Lecocq — Sun, 10 May 2026 15:00:02 +0000

The standard SaaS pricing for AI tools in 2026 looks like this: pay $49 a month, get 100 generations, anything beyond costs extra credits. The reason is simple. The vendor pays the model API per token, marks it up to cover infrastructure plus margin, and caps your usage so they do not lose money on heavy users.

I went the other way. Users on my LinkedIn tool bring their own OpenAI, Anthropic, Google, or Grok key. They pay the AI provider directly, at the provider's pricing. I charge a flat $19 a month for the platform itself, with no token caps.

The math the user sees: $19 to me + $2-4 a month to OpenAI for typical usage = $21-23 total. The competitor charging $49 with caps costs them more, gives them less, and runs out faster.

This article is about why this works, what the architecture looks like, and what tradeoffs you accept when you go BYOK.

The cost math

Take a typical creator generating 30 LinkedIn posts a month with GPT-4o or Claude Sonnet. Each generation is roughly 2,000 input tokens (your context, voice samples, brand info) plus 800 output tokens. At current OpenAI prices, that is about $0.03 per generation. Thirty a month: $0.90.

Add some image generation: 4 LinkedIn carousels, 8 hook variations tested. Maybe $1.50 in image cost.

Total monthly AI cost for an active user: $2-3. Heavy users hit $5-8. None of them hit $20.

Meanwhile, the standard SaaS markup is 5-10x. The vendor sees the same $2-3 in API cost and charges $49. Caps usage so heavy users do not eat the margin. Adds "credits" to upsell on overage.

BYOK eliminates the markup entirely. Users pay the API at API prices.

The architecture

The user stores their own API key in their account. My app reads it at request time and calls the provider directly.

async function generatePost(userId: string, prompt: string) {
  const user = await getUser(userId);
  const key = decrypt(user.encryptedOpenaiKey);

  const openai = new OpenAI({ apiKey: key });
  const result = await openai.chat.completions.create({
    model: user.preferredModel ?? "gpt-4o",
    messages: buildMessages(prompt, user.voiceProfile),
  });

  return result.choices[0].message.content;
}

The platform never proxies API requests. It just decrypts the key on the request hot path and uses it. No vendor middlemen, no rate-limit aggregation, no shared infrastructure billing.

Storage: the API key is encrypted at rest with a per-user secret derived from your platform's master key plus the user ID. I use AES-256-GCM. Never log the key. Never return it in responses (return a masked version like sk-...AbCd for the UI).

What you give up

There are real tradeoffs. Pretending there are not is dishonest.

You cannot offer a "no setup, click and go" experience. Users have to create an account on OpenAI or Anthropic, generate a key, and paste it into your settings. That is friction. It eliminates the casual try-it crowd. Some of them never come back.

You cannot promise a fixed monthly cost. A new user does not know what their AI usage will look like. Telling them "between $2 and $8 depending on usage" is true but feels uncertain. Users like fixed numbers.

You cannot enforce per-user quotas centrally. If a user gives their key to four people, you cannot stop that. The provider stops them when they hit their own provider limits. From your side, that is fine. From a "use case enforcement" perspective, it is a gap.

Support gets weirder. When generations fail, the question is now "is it your code or my API key." Users blame you for provider errors. You build error mapping that surfaces "this is an OpenAI 429, not us." It works but it is more code than a single-tenant setup.

When BYOK is wrong

BYOK does not fit every product. Three cases where it fails:

Your model is fine-tuned or proprietary. If you trained on your own data and serve a custom endpoint, you cannot let users bring their own key. There is no key to bring.
Your users are non-technical and the API key step kills them. B2C tools targeting "anyone can do it" audiences lose 30-50% of signups at the key step. If your audience is "marketers who do not know what an API is," do not BYOK.
Your value is in the routing, caching, or aggregation. Tools that route a single request across multiple models, cache embeddings across users, or aggregate inference costs across a tenant cannot easily go BYOK.

For my use case (LinkedIn content generation, technical-leaning audience, no caching benefit because each user's voice is unique), BYOK is a clean win. It would be wrong for a different audience or different value proposition.

The pricing pitch

When a user looks at a competitor at $49 a month with a 100-post cap, then looks at $19 a month plus $2-4 in API costs and unlimited generation, the math is a hard yes. The friction of pasting an API key is real but it is a one-time cost. The price difference is a recurring cost.

Most BYOK conversions happen on the second visit. They see the architecture, leave, do the math, come back. The first visit is too noisy for the tradeoffs to land.

If you are pricing an AI SaaS and your only differentiator is the model output, BYOK is worth modeling. The margin you give up is offset by the conversion you gain on price-sensitive users.

Scheduling Posts Exactly On Time With QStash + Next.js

Nicolas Lecocq — Sat, 09 May 2026 15:00:01 +0000

I needed to schedule LinkedIn posts to publish at exact times chosen by users. Vercel cron supports cron expressions, so I figured I would run a job every minute and check if any post should publish in the next minute. That works. It is also wasteful, fires a function 1,440 times a day, and on free Vercel plans you only get a 1-minute resolution which is not exact.

I switched to Upstash QStash. Same family as Redis, separate product, designed for delayed and scheduled HTTP requests. The setup ended up cleaner than the cron approach and runs at the exact second.

What QStash actually does

You publish a message to QStash with a target URL and a delay or cron expression. QStash sits on the message until the time is right, then makes an HTTP POST to your URL with whatever body you set. It signs the request so you can verify it came from QStash.

For one-off scheduling, you publish once with a delay or notBefore parameter. For recurring jobs, you create a schedule with a cron expression. Both go through the same delivery path.

The publish call

For a post the user wants to schedule at a specific timestamp:

import { Client } from "@upstash/qstash";

const qstash = new Client({ token: process.env.QSTASH_TOKEN! });

const targetUrl = `${process.env.NEXT_PUBLIC_APP_URL}/api/linkedin/publish-scheduled`;

const result = await qstash.publishJSON({
  url: targetUrl,
  body: { postId: "abc123", userId: "user_456" },
  notBefore: Math.floor(scheduledAt.getTime() / 1000), // unix seconds
});

// store result.messageId so you can cancel later

The notBefore field is a unix timestamp in seconds. QStash will not deliver before that time. Delivery typically happens within a second of the target time, in my testing.

The messageId from the response is what you use to cancel the schedule later. Store it on the post row.

Receiving and verifying

The route that QStash calls has to verify the signature. Without verification, anyone could POST to your endpoint and trigger publishing.

import { Receiver } from "@upstash/qstash";

const receiver = new Receiver({
  currentSigningKey: process.env.QSTASH_CURRENT_SIGNING_KEY!,
  nextSigningKey: process.env.QSTASH_NEXT_SIGNING_KEY!,
});

export async function POST(req: NextRequest) {
  const body = await req.text();
  const signature = req.headers.get("upstash-signature") || "";

  const isValid = await receiver.verify({
    body,
    signature,
    url: `${process.env.NEXT_PUBLIC_APP_URL}/api/linkedin/publish-scheduled`,
  });

  if (!isValid) {
    return NextResponse.json({ error: "Invalid signature" }, { status: 401 });
  }

  const { postId, userId } = JSON.parse(body);
  // ...do the actual publishing
  return NextResponse.json({ ok: true });
}

Two signing keys: current and next. QStash rotates them periodically and your verifier accepts both during the rotation window. Set them up once in your env vars and forget about them.

Cancellation

When the user unschedules a post, you delete the QStash message:

await qstash.messages.delete(post.qstashMessageId);

If the message has already been delivered, this returns 404 and you ignore it.

When to use cron schedules vs one-off

QStash supports both. I use publishJSON for user-scheduled posts because each one needs its own target time. For things like "run this every day at 14:00 UTC" (cleanup jobs, daily syncs), I use schedules.create once at deploy time:

curl -X POST "https://qstash-us-east-1.upstash.io/v2/schedules/$DESTINATION" \
  -H "Authorization: Bearer $QSTASH_TOKEN" \
  -H "Upstash-Cron: 0 14 * * *" \
  -H "Upstash-Retries: 2" \
  -d '{}'

Two retries on failure, daily at 14:00 UTC. The schedule lives until you delete it.

What QStash does not do

It does not run code. It calls your URL. You still need a Next.js route handler doing the work.
It does not give you transaction guarantees. If your handler fails after partially completing, you handle that.
It is not free past the lowest tier. The free tier is generous (500 messages a day at the time of writing), but a busy app outgrows it.

The before/after

With Vercel cron, my "publish scheduled posts" job ran 1,440 times a day. Most of those runs found nothing to do. Function invocations on Vercel cost money past the free quota.

With QStash, I run zero idle invocations. Each scheduled post triggers exactly one function call at the exact time the user wanted. My cost dropped, my logs got cleaner, and the publish-time accuracy went from "within the next minute" to "within 1-2 seconds of the requested time."

If you are building anything that needs to run code at a specific time the user chose, QStash is worth the 30 minutes of setup.

Posting to LinkedIn From Node.js: 7 API Quirks That Burned Me

Nicolas Lecocq — Fri, 08 May 2026 15:00:01 +0000

I built a tool that posts to LinkedIn programmatically. Here is the list of things I wish I had known before I started, with code where it helps. None of these are documented prominently. All of them cost me an evening or two.

1. Author URN, not user ID

When you create a UGC post, the API does not accept a user ID. It accepts a URN like urn:li:person:abc123. If you store the LinkedIn user ID as a string and try to send it directly, you get a INVALID_AUTHOR error with no further detail.

const authorUrn = `urn:li:person:${user.linkedinProfileId}`;

For company pages, it is urn:li:organization:12345. You must store the URN type along with the ID, or compute it at request time based on whether you are posting as a person or a company.

2. The image upload is three calls, not one

You cannot just send a base64 image in the post body. The flow is:

POST /rest/images?action=initializeUpload with the author URN. Response includes an uploadUrl and an image URN.
PUT the binary image bytes to that uploadUrl. No auth header. LinkedIn's signed URL handles auth.
POST your share with the image URN in the media field.

// Step 1
const init = await fetch(
  "https://api.linkedin.com/rest/images?action=initializeUpload",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${token}`,
      "Content-Type": "application/json",
      "LinkedIn-Version": "202401",
      "X-Restli-Protocol-Version": "2.0.0",
    },
    body: JSON.stringify({
      initializeUploadRequest: { owner: authorUrn },
    }),
  }
);
const { value } = await init.json();
const uploadUrl = value.uploadUrl;
const imageUrn = value.image;

// Step 2 — note: no auth header on the PUT
await fetch(uploadUrl, { method: "PUT", body: imageBuffer });

// Step 3 — use imageUrn in your share

If you skip the LinkedIn-Version header, you get a 400 with no explanation. The version is a date string, not a semver.

3. Empty body returns 422, not 400

If you POST a share with commentary set to an empty string, LinkedIn returns 422 Unprocessable Entity. If you omit commentary entirely, you also get 422. The error message says nothing useful. The fix is to always send at least one space if the user wanted an image-only post:

commentary: text?.trim() || " ",

4. Rate limits are silent

There is no X-RateLimit-Remaining header. There is no documented per-user limit. Your app has a daily quota you can see in the developer portal, but per-user behavior is enforced at LinkedIn's discretion. If you post too fast on the same user account, you start getting 429 errors with a generic message. Back off exponentially. Plan for 5 to 10 posts per user per day as a soft ceiling, even if your own users would never hit that.

5. Token expiry is real, refresh is opt-in

Access tokens are valid for 60 days. After that, the API returns 401 with a REVOKED_ACCESS_TOKEN error. You can opt into refresh tokens by adding offline_access to your scopes, but only if your app has been approved for it. Most apps are not. Plan to re-prompt users for consent every 60 days, or apply for the refresh flow if your use case justifies it.

6. Scope creep does not apply retroactively

If you grant a user openid profile email today and add w_member_social next week, the user's existing access token does NOT include the new scope. You need to re-run them through OAuth with the new scopes. The token they get back includes the union of new and previously granted scopes.

The annoying part: there is no clean way to detect "this user needs to re-auth" from the API. You only find out when you try to call an endpoint that requires the new scope and it returns 403. Track the scopes you requested per user in your own database and compare against your current code.

7. The consent screen caches aggressively

If you change scopes during development and try to test, LinkedIn shows the user the cached consent from last time. The token comes back with the OLD scopes. You will spend time wondering why your code is not picking up the new scope you added.

Two fixes:

// Option A: force consent every time during dev
authorization: { params: { scope: "...", prompt: "consent" } }

// Option B: have the user revoke the connection in their LinkedIn settings

Use option A while developing. Drop it for production because forcing consent every login annoys users.

That is the list. None of these are exotic. All of them have bitten me more than once. Bookmark this if you are building anything that touches LinkedIn programmatically.

Reverse-Engineering LinkedIn's 360Brew From Their Engineering Blog

Nicolas Lecocq — Thu, 07 May 2026 15:00:01 +0000

LinkedIn quietly replaced its feed ranking system in 2026. Not with a tweaked version of the old one. With a single 150-billion-parameter language model called 360Brew, built on top of LLaMA 3 and fine-tuned on internal data. They published the technical details on their engineering blog. Most people did not read it.

Here is what the paper actually says, with the parts that matter for anyone building on or analyzing the platform.

What it replaced

The old LinkedIn ranking pipeline was a chain of around thirty specialized models. Each one scored a numerical feature: dwell time, sender-receiver affinity, click-through rate, comment likelihood, and so on. The features were stitched together by a final ranking layer that picked which posts to show.

This is the same pattern most social platforms have used since the 2010s. It is fast, cheap, well-understood, and easy to A/B test. The downside is that it can only see what the engineers thought to measure. Anything outside those features is invisible.

What 360Brew does instead

360Brew is one decoder-only model. It takes a post, the author profile, the candidate reader profile, and recent interaction history, and asks itself a single question: would this specific reader find this specific post worth engaging with.

The reason this matters: the model understands language. The old pipeline could count words but could not tell that a post about "Gong's revenue intelligence platform" and "Salesforce CRM workflows" are talking about the same thing. 360Brew can. That changes which posts get cross-cluster distribution.

It also changes which posts get punished. If the model decides a post sounds generic or rehearsed, it lowers the score regardless of how engagement-bait the structure is.

Concrete behaviors that changed

A few patterns I noticed by looking at my own posts and a friend's analytics, then matching against what the paper says is happening:

Hooks that worked in 2024 stop working. The "Stop scrolling. This will change your life." family of openers ranks lower because the model recognizes them as a pattern. Even small variations get caught.

Saves and long thoughtful comments matter more than likes. The old pipeline scored all engagement somewhat similarly. 360Brew weights interactions by how much intent they show, and saving is the biggest signal because it costs the user something.

Topic clusters lock in faster. Your profile gets classified into a topic cluster based on your last 60 to 90 days of posting. Once you are in a cluster, posting outside it gets capped. The old system was more forgiving about category drift.

Pods and engagement rings died. The old engagement-counting models could not tell the difference between "200 people who care liked this" and "200 people in a pod liked this." 360Brew sort of can, by reading the comments. If the comments are off-topic or generic, the model assumes the engagement is fake and downweights distribution.

Why this matters for builders

If you are writing tools that touch LinkedIn data, you cannot rely on the old engagement-rate metrics anymore. Two posts with identical likes and comments can have wildly different reach because 360Brew weighs the quality of the engagement, not just the count.

A few practical implications for any tool that schedules, generates, or analyzes LinkedIn content:

Scoring "good content" by like-prediction is now wrong. The model rewards substance, not engagement-bait. Your scoring model should reward specificity, not virality patterns.
Voice-matching matters more than format-matching. The old algo loved certain formats (line-broken hooks, three-bullet bodies). 360Brew does not care about format. It cares whether the post says something a real person would say.
Comment quality is a real ranking signal now. If you build comment automation, the model can tell. Generic comments hurt your distribution score.

The part the paper does not say

The paper is careful to never give actual weights or thresholds. No "saves count X times more than likes." No "the topic cluster window is exactly 60 days." Those numbers are inferred from creator behavior, not declared.

That means anyone telling you the exact recipe for going viral under 360Brew is making it up. The honest answer is the model rewards posts that say something specific, posted into a topic cluster the author has been building, and engaged with by people in that cluster within the first hour.

The full paper is on the LinkedIn Engineering Blog. Worth reading even if you do not build on LinkedIn. It is one of the cleaner public write-ups of replacing a feature-engineering pipeline with a foundation model.

Sign In With LinkedIn Using OpenID Connect in Next.js 16

Nicolas Lecocq — Wed, 06 May 2026 19:24:12 +0000

LinkedIn finally moved Sign In to OpenID Connect a while back. Most of the tutorials still floating around the internet show the legacy v1 OAuth dance with r_liteprofile and r_emailaddress scopes. Those are deprecated. If you copy them, your callback will work for a while and then mysteriously stop, which is the worst kind of bug.

Here is the flow that actually works in 2026 with Next.js 16 and NextAuth v5.

The scopes you want

Forget r_liteprofile and r_emailaddress. The current Sign-In product asks for:

openid profile email

Three scopes, lowercase, space separated. That is the entire request. LinkedIn returns a standard OIDC ID token plus a regular access token. No more profile-specific endpoints, no more email-specific endpoints. The user identity ships in the token claims.

The provider config in NextAuth v5

NextAuth v5 has a built-in LinkedIn provider, but it ships with the legacy scopes. You need to override it. Here is the working config:

// src/lib/auth.ts
import LinkedIn from "next-auth/providers/linkedin";

export const { auth, handlers, signIn, signOut } = NextAuth({
  providers: [
    LinkedIn({
      clientId: process.env.LINKEDIN_CLIENT_ID!,
      clientSecret: process.env.LINKEDIN_CLIENT_SECRET!,
      issuer: "https://www.linkedin.com",
      authorization: {
        params: { scope: "openid profile email" },
      },
      token: "https://www.linkedin.com/oauth/v2/accessToken",
      userinfo: "https://api.linkedin.com/v2/userinfo",
      profile(profile) {
        return {
          id: profile.sub,
          name: profile.name,
          email: profile.email,
          image: profile.picture,
        };
      },
    }),
  ],
});

The two parts that trip people up: the userinfo endpoint is /v2/userinfo, not the legacy /v2/me, and the profile.sub field is what you want as the stable LinkedIn user ID. Do not use profile.id. It does not exist on the new endpoint.

Callback URL

In the LinkedIn Developer Portal, register exactly this:

https://your-domain.com/api/auth/callback/linkedin

If you forget the trailing path, LinkedIn returns a generic "Bummer, something went wrong" page with no useful debug info, and you will spend forty minutes wondering if you broke your environment variables. Ask me how I know.

Storing the access token

The OIDC ID token tells you who the user is. The access token lets you call other LinkedIn APIs on their behalf, like posting to their feed. NextAuth v5 hands you both in the jwt callback:

callbacks: {
  async jwt({ token, account }) {
    if (account?.provider === "linkedin") {
      token.linkedinAccessToken = account.access_token;
      token.linkedinExpiresAt = account.expires_at;
    }
    return token;
  },
}

Persist linkedinAccessToken to your database row for the user, plus the expiry timestamp. LinkedIn's access tokens are valid for 60 days. They do support refresh tokens now, but only if you specifically request the offline_access scope, which most apps do not need. For a 60-day window, store it, check the expiry on each use, and re-prompt if expired.

What you do not get from OIDC

Sign-In gives you identity. It does not give you posting rights. To post on someone's behalf, you need the separate w_member_social scope through the "Share on LinkedIn" product. Same OAuth, different consent screen, different scope. Apply for it through the developer portal.

Same story for company page management, feed reading, and the Community Management API. Each is a separate "product" you have to apply for in your LinkedIn app, and each has its own approval queue. Sign-In gets approved instantly. Posting takes a few days. Community APIs take longer and ask for use cases.

The bug to watch for

LinkedIn caches the consent screen aggressively. If you change scopes in your code and try to test, the user gets sent back to LinkedIn with the OLD consent already granted. The token they return does not include your new scopes. The fix: revoke the existing connection in their LinkedIn account settings, or pass prompt=consent in the authorization params:

authorization: {
  params: { scope: "openid profile email", prompt: "consent" },
}

This forces a fresh consent dialog every time. Use it during development, drop it for production.

That is the whole flow. Three scopes, one userinfo endpoint, one callback URL, one access token that lives 60 days. Most of the painful parts of the old LinkedIn OAuth went away when they moved to OIDC. The rest of the painful parts are documented above so you do not have to discover them at 2am.