DEV Community: Francisco José Fernández

Meta access token expired? Why it lasts 60 days and how to refresh it

Francisco José Fernández — Wed, 14 Oct 2026 12:05:30 +0000

An Instagram access token issued by Meta lasts 60 days. PlanVortex renews it automatically a day before it expires, so in normal use you never notice. You notice when that renewal fails: the account is flagged as down, stops retrying on its own, and your product gets a notification so it can ask the user to reconnect it.

Not every Meta token works like that. A Facebook Page token has no expiry date, a system user token lasts as long as you choose when you create it, and WhatsApp has a token of its own.

How long does a Meta access token last?

It depends on which token. These are the ones an integration meets:

Token	How long it lasts	How it is renewed
Instagram user token (Instagram Login)	60 days	`ig_refresh_token`, once it is 24 hours old
Facebook user token, long-lived	About 60 days	Through the login flow again
Facebook Page token, from a long-lived user token	No expiration date	It does not need renewing
System user token (Business Manager)	60 days or never, chosen at creation	`fb_exchange_token` with `set_token_expires_in_60_days=true`
WhatsApp token from the App Dashboard	A few hours	Generate a new one

For an Instagram account, 60 days is the window Meta documents for the long-lived token you get when connecting it, and it is fixed: you cannot request a longer one and there is no paid plan that extends it.

// src/orm/social_apis/instagram/index.ts
const expiresDate = new Date();
expiresDate.setSeconds(expiresDate.getSeconds() + (60 * 60 * 24 * 60)); // 60 days

That expiresDate is the only thing deciding whether an account needs renewing. There is no heuristic and no safety margin in that calculation: it is exactly 60 days from the instant Meta handed the token over, counted in seconds.

Why does the Instagram token expire when a Page token does not?

Because they stand for different things. The Instagram token is a user token: it represents the person who authorized the app, and Meta makes the integration come back every 60 days to show that person is still behind the permission. An expiry also limits the damage of a token that leaks (it stops working on its own, without anyone having to revoke it by hand).

A Page token generated from a long-lived user token represents the Page, and Meta says it has no expiration date and is only invalidated "under certain conditions". Meta's debugging guide lists what invalidates a token before its time: the person logging out of the app, changing their password or revoking the app's authorization. That is why PlanVortex renews Instagram accounts on a cycle and leaves Facebook Pages out of it.

Either way, whoever integrates the API has to treat a dead token as a normal part of the account lifecycle, whether it died on a date or because something invalidated it.

How is a token renewed before it expires?

With a job that runs once an hour and renews any account whose token is going to expire in less than 24 hours. The hourly cadence exists precisely so there is room to spare against that one-day window:

// src/domain/repositories/account/index.ts: "Refrescamos con 1 dia de diferencia (requerido por instagram)"
const now = new Date();
now.setDate(new Date().getDate() + 1);
const account_match = {
    deleted: false,
    error_code: 0,
    "access_data.expires_in": { $lte: now },
};

// src/jobs/index.ts
"refresh-tokens": {
    cron: "7 * * * *", // every hour, on minute 7
    run: refreshTokens,
},

The renewal itself is a call to Meta's refresh_access_token with grant_type=ig_refresh_token, which returns a new token with another 60 days ahead of it. As long as that call succeeds, the cycle repeats on its own and the account never learns its token changed.

How do you get a Meta access token that never expires?

There are two ways, and Meta is closing the second one.

A Page access token. Exchange the short-lived user token from the login dialog for a long-lived one, then ask for the Page tokens with it:

GET /oauth/access_token?grant_type=fb_exchange_token&client_id={app-id}&client_secret={app-secret}&fb_exchange_token={short-lived-user-token}
GET /{user-id}/accounts?access_token={long-lived-user-token}

Each Page in the second response carries its own access_token, and that one has no expiration date. Two conditions: the person asking must have a role on the Page, and the user token has to be the long-lived one, which is the input Meta asks for.

A system user token. In Business Manager (Business settings, then Users, then System users) you create a system user, give it the app and the assets, and generate a token. When you generate it you choose the expiry: never, or 60 days. Meta recommends the 60-day one as "a security best practice" and says that "all integrations should adopt expiring tokens". For businesses the requirement already applies to, asking for a non-expiring token returns an error. So the permanent system user token that many tutorials recommend may not be available to you.

A 60-day system user token is refreshed with the same exchange call plus one parameter:

GET /oauth/access_token?grant_type=fb_exchange_token&client_id={app-id}&client_secret={app-secret}&set_token_expires_in_60_days=true&fb_exchange_token={current-token}

The response brings a new token and its expires_in. Meta's advice is to refresh within the 60 days; once it lapses, you have to generate a new one.

Which token should you use for the WhatsApp Cloud API?

The token on the API Setup screen is only good for testing. The App Dashboard gives you a user token that, in Meta's words, expires quickly: you would have to generate a new one every few hours, which is enough to send a first test message.

For anything after that, it depends on whose number it is:

For your own business's number, a system user token, with everything said above about choosing 60 days or never.
For your customers' numbers (Meta calls you a Tech Provider), a Business Integration System User access token, one per customer, which you get by implementing Embedded Signup and exchanging the code the flow returns. Meta presents it as the way to reach each customer's assets without asking them to authenticate again. That is how PlanVortex connects WhatsApp: the customer goes through Embedded Signup and the code is exchanged on the server.

How do you check when a Meta token expires?

Meta's debug_token endpoint (the one behind the Access Token Debugger in its developer tools) returns, among other fields, expires_at and data_access_expires_at:

GET /debug_token?input_token={token-to-check}&access_token={app-id}|{app-secret}

They are two different dates. expires_at is when the token stops working. data_access_expires_at is the data access window, 90 days from the person's last activity: past it, the person can still log in, but the app loses access to their data until they re-authorize the permissions. PlanVortex calls debug_token when it connects a WhatsApp account, to read which assets the person granted and when the token expires.

Do tokens last the same on every network?

No: each network forces its own deadline, and renewal code that treats them all alike ends up with dead accounts.

Network	access_token lifetime	Source
Instagram (Meta)	60 days	`instagram/index.ts`
Facebook Page (Meta)	No expiration date	absent from `getAccountsToRefresh`
LinkedIn	60 days (5,184,000 s)	`__tests__/social/contract/linkedin.test.ts`
TikTok	24 hours	`__tests__/social/contract/youtube.test.ts`
YouTube (Google)	1 hour	`youtube.types.d.ts`

YouTube is the extreme case: with a token that lasts an hour, the hourly job is not enough on its own, so its SDK also renews on demand before every call. Instagram and LinkedIn, at 60 days, live comfortably inside the hourly pass with room to spare. Facebook Pages sit at the other end: their token has no date, so they never enter the pass. The practical consequence is that the renewal code cannot be generic: each SDK knows how long its own token lasts and which field of the response carries the new expiry, because they are not even named the same across networks.

What happens the day the token really expires?

The automatic renewal fails, and from that point the account stops trying on its own. This only happens if something prevented the 60-day cycle from closing in time (the user revoked the permission from Meta, the app lost its approved use case, or the job had been unable to run for more than a day), never from the mere passing of 60 days with the system working normally.

When the renewal call fails, three things happen at once:

The account is flagged with an error code (error_code: 707, "Error while sincronyzing").
That code takes it out of the job's next pass: the query selecting accounts to renew requires error_code: 0, so a downed account is not retried every hour against a token that no longer works.
A change_state_account change is queued and notified by signed webhook to the client apps that have that client registered.

The job processes every account due for renewal in that pass in parallel, grouped by client. That matters because a client with several Instagram accounts can have one fail and the rest renew without trouble in the same pass: one failure neither blocks nor delays the others, and the webhook that reaches the client app carries that client's changes grouped together, not one message per account.

// src/jobs/RefreshTokens.ts
} catch (e) {
    await AccountModel.updateOne({ _id: account._id }, { $set: { error_code: CustomError.ERROR_CODE_707.key } });
    addAccountChange(grouped, account, {
        field: ALLOWED_WEBHOOKS_NOTIFICATIONS.change_state_account,
        id_account: account._id.toString(),
        id_organization: account.id_organization._id.toString(),
        social_network: account.social_network,
    });
}

How does your product find out an account disconnected?

Through a webhook, as soon as the job detects the failure. If your app integrates the PlanVortex API, the change_state_account webhook reaches you with id_account, id_organization and social_network, signed like every other outbound PlanVortex webhook.

Finding out through a publishing error is too late: the user scheduled content for three days out assuming the account was still connected, and the failure does not surface until that content tries to go out. With the webhook, your product can warn the user the same day the account went down, with plenty of time to reconnect it before anything is left unpublished.

What should you have settled if you integrate Meta accounts into your product?

Four things, before assuming a connected account is still connected:

A disconnected account is a state, not an error. It happens in normal use (the user revokes the permission from Meta's settings, changes their password, the app loses access) and your product has to be able to show that without treating it as an exception.
Listen to the webhook as well as to the publishing error. It is the difference between warning on the day the account goes down and warning on the day something scheduled fails because of it. The code that receives it (signature verification over the raw body included, which is where everyone trips) is in the Node.js and Python guides.
Reconnection is always manual. Neither PlanVortex nor Meta can renew a permission the user has revoked; the flow to connect the account is the same one as the first time, authorization code included.
The message to the user cannot be generic, because networks do not fail the same way. A downed TikTok account and a downed Instagram account share neither the most likely cause nor the urgency: with a 24-hour token, a TikTok failure is almost always a one-off problem with the job; with a 60-day one, an Instagram failure almost always means the user revoked the permission.

Is the LinkedIn API free? Pricing and posting access in 2026

Francisco José Fernández — Tue, 13 Oct 2026 12:17:24 +0000

LinkedIn charges nothing per API call, but posting to a company page takes its approval. Posting to your own profile is self-serve. Company pages need the Community Management API, which LinkedIn grants only to registered companies after a review, and which starts with a cap of 500 calls a day for the whole app.

How much does the LinkedIn API cost?

Nothing per call. LinkedIn's developer documentation describes access tiers and reviews, with no price list and no paid plan that buys more. What you do pay is a review before you can post to a company page, a daily cap while you are in the first tier, and upkeep: the API version you send expires, and so does every connection, once a year.

There are three ways in:

Product	Where it posts	How you get it	Daily limit
Share on LinkedIn	Your own profile (`w_member_social`)	Self-serve: add the product to your app in the Developer Portal	150 requests per member, 100,000 per app
Community Management API, Development tier	Company pages and profiles	An access form that LinkedIn reviews	500 calls per app and 100 per member, every 24 hours
Community Management API, Standard tier	The same, in production	A second form, with a screencast of your app	No restrictions

Figures from LinkedIn's Increasing Access and Share on LinkedIn pages, read on October 6, 2026.

Can you use the LinkedIn API for personal use?

Only to post as yourself. Share on LinkedIn gives any app the w_member_social permission without a review, and that is enough to publish to the profile of whoever authorizes it. For a script that posts your own updates, that is the route.

Company pages are another matter. LinkedIn's review page says "our Community Management APIs are only available to registered legal organizations for commercial use cases only", and personal email addresses won't pass the vetting, so a side project has no way to post to a company page.

Share on LinkedIn's documentation still shows the old /v2/ugcPosts endpoint, while the current Posts API at /rest/posts "replaces the ugcPosts API", in LinkedIn's own words. Write against /rest/posts from the first day and there is nothing to migrate when you move up a tier.

How do you get access to post on a LinkedIn company page?

You apply for the Community Management API from your app in the Developer Portal. For the Development tier, LinkedIn checks five things: an approved use case, a verified business email, a verified organization, a verified website and domain, and that the LinkedIn Page of that same organization has verified the app, which takes one of the Page's super admins.

Three of its rules change how you plan:

A rejection is final for that app. In LinkedIn's words: "You won't be able to re-apply for Development tier access with your existing app." You create a new app and start over.
The Development tier has a deadline: you have twelve months to apply for Standard, and after that LinkedIn removes your access for inactivity.
The 500 calls a day are for the whole app, shared by all your customers. In our SDK, a post with one image takes four requests: start the upload, send the bytes, read the image back and create the post. Statistics and comments come on top. Batch reads (BATCH_GET) are blocked, and webhooks for social actions stay off until Standard.

The Standard tier asks for more: test credentials, a high-resolution screencast that shows a user going through the full OAuth flow and each use case you declared (for page management, a post and how a comment on it shows up in your app), a valid privacy policy, and compliance with LinkedIn's data storage rules.

Why does the LinkedIn API return 426?

Because the Linkedin-Version header asks for a version that LinkedIn has retired. The response is documented like this:

{
  "status": 426,
  "code": "NONEXISTENT_VERSION",
  "message": "Requested version yyyymmdd is not active"
}

LinkedIn publishes a version every month, in YYYYMM format, and supports each one for at least a year. Leaving the header out does not get you the latest one: LinkedIn documents a 400 with the code VERSION_MISSING. The oldest version still in the documentation, 202510, is sunset on October 15, 2026, and a header pinned to 202501, from January 2025, already gets the 426.

The fix is to send a live version. In our SDK it lives in one constant:

// src/orm/social_apis/linkedin/constant/index.ts
LINKEDIN_API_VERSION: "202606",

// and every request carries the same three headers
{ Authorization: "Bearer " + access_token, "Linkedin-Version": LINKEDIN_API_VERSION, "X-Restli-Protocol-Version": "2.0.0" }

Keep the version in a single constant, note the date it expires in a shared calendar, and run at least one test against the real API: a test with mocked responses keeps passing after the version is retired.

Why is your LinkedIn post cut off with no error?

Because the body of the post is not plain text. The commentary field of /rest/posts is written in little text, a small format for mentions and hashtags with fifteen reserved characters, and the documentation is explicit: "All reserved characters need to be escaped with a backslash, even if those characters are not used in one of the supported elements or templates."

If you don't escape them, LinkedIn still answers 201 with the post id, and the post shows up cut off at the first unescaped character. A price in brackets, "(30€ + VAT)", is enough to take the rest of the post with it, links included. Nothing in the response or in your logs shows it; you only see it on LinkedIn.

// src/orm/social_apis/linkedin/Text.ts
const RESERVED_PATTERN = /[\\|{}@\[\]()<>#*_~]/g;

The escaping has to be a single pass, because the backslash is reserved too: escape it in a second step and the \( you just added gets published as \\(. And a # that opens a real hashtag must stay as it is, or the hashtag is published as dead text. A #1 that is just a number gets escaped like everything else.

The post has two size limits as well. The body takes up to 3,000 characters. The title of an attached image or video, content.media.title, takes 400, and past that LinkedIn answers 422 with length of "..." is out of range 0...400. That title is not little text, so it is not escaped: escaping it would publish the backslashes.

How long does a LinkedIn access token last?

60 days. Apps approved for LinkedIn's marketing programs also get a refresh token that lasts 365 days, and the documentation is clear that using it does not extend it. Renew on day 59 and the refresh token has 306 days left; when it reaches zero, "the member must reauthorize your application". So every LinkedIn connection ends after a year, however well your renewal works. Apps without that approval get no refresh token at all, and the user has to go through the authorization screen every 60 days.

The token belongs to the person who authorized the app, and it covers their profile and every page they administer. If you store one row per page, renew per person and write the new token to every page that came from that authorization.

When a connection ends, handle it as the Meta token article describes: show the account as disconnected and ask the user to connect it again.

Do you need your own LinkedIn app if you integrate through PlanVortex?

No. Your customers connect their LinkedIn pages, and their personal profiles too, through PlanVortex's app, which has the Community Management API at the Standard tier, so the Development tier's cap of 500 calls a day does not apply to them. The access form, the screencast and the version header are our job. Two things stay on your side: the person authorizes again when LinkedIn asks for it, and your product finds out through the signed change_state_account webhook as soon as a renewal fails.

The developers page shows the API, the Node and Python libraries and the MCP server that sit on top of that app. With the MCP server, Claude or Cursor can post to LinkedIn for you, to your profile and your pages.

If you only want to post to your own company pages or your own profile, you don't need to write code at all: the panel does it, and the first three accounts are free. On paid plans, its AI planner also writes the week's posts, with images or from your own photos.

It isn't the right tool if what you need is LinkedIn advertising. Campaigns and ad accounts live in the Advertising API, a separate product with its own review.

Where do you go from here?

Publishing from Node.js and from Python: connect a customer's LinkedIn page and publish to it, webhook verification included.
Character limits across social APIs: which unit each network counts in, LinkedIn included.
A LinkedIn MCP server on the official API: post to your profile and pages from Claude, Cursor or VS Code.

Character limits across social APIs: .length lies, and it lies both ways

Francisco José Fernández — Wed, 16 Sep 2026 11:40:43 +0000

"👨‍👩‍👧‍👦".length is 11. That emoji is one character on screen, seven Unicode code points, and 25 bytes on the wire. Which of those numbers a social network measures your post against depends on the network — and if you pick the wrong one, you either reject posts that would publish fine or accept posts the API will refuse hours later, when the thing is already scheduled.

This is what we learned building a publishing API against thirteen networks, with the numbers taken from the real APIs rather than from their documentation.

Three units, one string

Every discussion about character limits is really a discussion about units. There are three that matter, and a fourth that looks useful and is not:

const seg = new Intl.Segmenter(undefined, { granularity: "grapheme" });

const text = "👨‍👩‍👧‍👦";
text.length                                  // 11  — UTF-16 code units
[...text].length                             //  7  — Unicode code points
[...seg.segment(text)].length                //  1  — graphemes
new TextEncoder().encode(text).length        // 25  — UTF-8 bytes

Text	`.length`	code points	graphemes	bytes
`👨‍👩‍👧‍👦`	11	7	1	25
`🙂`	2	1	1	4
`é`	1	1	1	2
`漢`	1	1	1	3

The family emoji is four people joined by three zero-width joiners, which is why spreading the string — the trick everyone reaches for first — gives 7 and not 1. Code points are never the answer to anything here.

Which unit does each network count in?

Network	Limit	Unit
Facebook	63,206	UTF-16
YouTube (description)	5,000	UTF-16
WhatsApp	4,096	UTF-16
Telegram	4,096, or 1,024 with media	UTF-16
Slack	4,000	UTF-16
LinkedIn	3,000	UTF-16
Instagram	2,200	UTF-16
TikTok	2,200	UTF-16
Discord	2,000	UTF-16
Threads	500	graphemes
X	280	UTF-16
Bluesky	300 and 3,000	*graphemes and* bytes**

Most networks count UTF-16 code units, which is exactly what .length returns. That is the trap: .length is right often enough that you stop questioning it, and then you meet the two networks where it is wrong.

TikTok's row hides a second lesson. Its app lets you type 4,000 characters; its Content Posting API rejects past 2,200. The number that matters is the one belonging to the endpoint you actually call, never the one in the network's own UI.

Bluesky counts two limits at once, in different units

Bluesky is the only network with two text limits alive at the same time: 300 graphemes and 3,000 bytes, and a post has to pass both.

.length fails both, in opposite directions:

It over-counts emoji. 121 family emoji are 121 graphemes — comfortably inside 300 — so they should publish. .length says 1,331 and rejects them.
It under-counts everything non-Latin. Those same 121 emoji weigh 3,025 bytes, which is over the byte limit. Counting characters alone says they fit; the network says no. A long text in Japanese does the same thing: three bytes per character, and a post that looks short blows the byte ceiling.

So the check has to be two checks:

const graphemes = countGraphemes(text);           // Intl.Segmenter
const bytes = countBytes(text);                   // Buffer.byteLength / TextEncoder

if (graphemes > 300 || bytes > 3000) {
    // reject, and tell the user WHICH of the two it was
}

Telling the user which limit they hit is not a nicety. "Too long" in front of a counter that says 180 characters is an unanswerable error message.

Threads counts graphemes, and we only know because we measured

The documentation says "500 characters" and adds, unhelpfully, that emoji count as UTF-8 bytes. Two readings, both plausible, and they disagree. So we sent two probes at a real account:

400 × 🙂 — 400 graphemes, 800 UTF-16 units, 1,600 bytes → publishes.
400 × é — 400 graphemes, 400 UTF-16 units, 800 bytes → publishes.

Both are over 500 in at least one of the other two units, so neither UTF-16 nor bytes can be the ruler. It counts graphemes.

Before that measurement our validation used .length, which meant a post of 300 emoji was rejected as too long while the network would have accepted it. That is the expensive direction of the two. A post the API refuses produces an error you can read; a post your own product refuses produces a user staring at a counter that says 300 of 500 and a message saying it is too long.

Telegram changes its limit when you attach a photo

Same text field, two numbers:

4,096 with no attachment, because the text goes out as sendMessage.
1,024 the moment there is a photo or a video, because then the text is the caption of sendPhoto, sendVideo or sendMediaGroup.

This is not an edge case in a publishing tool, it is the normal case: someone writes 2,000 characters, likes it, drags in an image, and the post that was valid a second ago now fails with a 400 at publish time. The counter in the composer has to change the instant the file is attached, and the error — if it still happens — has to say that the limit dropped because of the file.

Slack does not fail, which is worse

Slack's limit is 4,000 characters for chat.postMessage, and going over does not produce an error. It truncates the message, or splits it into several. Your dashboard shows one published post; the channel holds two; nothing failed anywhere.

Slack has a second trap in the same area. Its text has to be escaped — &, < and > are the start of Slack's own entities, and an unescaped < swallows the rest of the sentence — and escaping changes the length. & becomes &, five characters where there was one. So the 4,000 check counts the user's text, because that is what the composer counts, while any safety trim measures the escaped string, and has to cut without leaving half an entity behind. Cutting at character 4,000 flat once published a visible &am.

How to count each unit properly

/** Graphemes: what a person calls "a character". */
export const countGraphemes = (text: string): number =>
    [...new Intl.Segmenter(undefined, { granularity: "grapheme" }).segment(text)].length;

/** UTF-8 bytes: what the wire carries. */
export const countBytes = (text: string): number => Buffer.byteLength(text, "utf8");

Two practical notes. Intl.Segmenter needs your TypeScript lib at ES2022 or later — ours is pinned there while target stays lower, purely for this. And segmenting is not free: it allocates a segment per grapheme, so count once and pass the number around rather than calling it in a loop over a thousand posts.

The rule that prevents all of this

Every bug above is cheap to fix once. The expensive one is structural: the screen that counts and the server that validates keeping separate copies of the numbers.

Ours drifted exactly that way. The composer counted LinkedIn to 3,000 while the server rejected at 1,300 — a number left over from an endpoint we no longer called — and the user found out at publish time, which is the worst moment available. The fix was not a better number. It was one source of truth, owned by whoever validates, and published:

curl https://api.planvortex.com/v1.0.0/social_limits \
  -H "Authorization: Bearer $TOKEN"

That endpoint returns the character limit, the byte limit, the title limit, image counts, video duration and file size for every network, so a composer never has to hardcode a single one of them. Whoever enforces a limit is who gets to announce it.

If you are building the same thing, that is the piece worth copying even if you take nothing else from this article. And if you would rather not build it at all, PlanVortex's API does the counting for you — in the right unit, per network — before anything reaches the network.