What a credit is

One rule, and every price on this site derived from it.

On this page

A credit is a unit of upstream work, not a unit of money. It has exactly two bases, and every number in the table below is one of them or a sum of them. If you find a price you cannot derive, it is a bug in the price list.

A direct fetch costs what it costs us #

One credit per request we make to LinkedIn to answer you. A company is one fetch, so companies/enrich is 1. A profile is one fetch, so profiles/enrich is 1. A profiles/activity call is one fetch for the profile plus one per feed you asked for, so it is up to 4.

A section costs half #

profiles/enrich/detailed is the one place we charge less than the rule. Each of its optional sections is a further request to LinkedIn and each is +0.5, because a section is an extra on a record you are already buying a credit's worth of. That is the only direction the rule bends: we may quote you more than we spend, never less.

A search row costs half #

Sales Navigator hands us 100 rows per request, and the request is the unit you are billed in: 50 credits, which is those 100 stubs at the half credit a stub is worth rather than the whole credit a record costs. The request is what we spend and what LinkedIn throttles us on, so a page that comes back short or empty costs what a full one costs - and max_results rounds up to a whole request, with the overflow delivered rather than discarded.

A chunk is a request even when it matches nobody #

sales/search/employees runs one search per chunk of your company list, and a chunk whose fifty companies employ nobody your search matches is still a request we made. So a chunk page is billed at the greater of its rows and one credit. That is the same rule, not an exception to it: the per-row price expresses "one credit is one request" accurately from two rows up and rounds to zero below it, which on a plain search happens once at the end of a run and here can happen on every chunk.

Three consequences #

  • Resolution is charged, because it is a fetch. Every profile-scoped activity operation costs one more than the thing you asked for: the profile has to be fetched before its activity can be addressed. That is the "1 profile" in every breakdown.
  • Optional work is an optional flag. Enriching a search row runs the matching enrich operation per row and adds exactly that operation's price. Off by default. Nothing ever costs more than the table says without a flag you set.
  • A failure costs 0. A failed fetch produced nothing, so there is nothing to bill. This is not a pay-on-success promise bolted on top - it falls out of what a credit is.

Credits divide; the ledger does not #

Costs are quoted to one decimal - a detail section is 0.5. Internally the unit of account is one hundredth of a credit, stored as an integer, and every charge, balance and quota comparison is integer arithmetic in that unit. No column holds a float.

That is not fussiness. A float balance accumulates error invisibly and surfaces months later as a quota refusing a request it should have allowed - the one billing bug a customer cannot audit from their own side and will not forgive.

A partially served target #

You are charged for the fetches that landed, and the result entry says so. A profiles/activity call whose reactions feed was refused is 3 rather than the 4 it quoted, and a profiles/enrich/detailed target that got every section is 3.5 while one whose experience section was refused is 3.

The single-feed operations have no partial case. profiles/posts, profiles/comments and profiles/reactions ask for one feed, so a refusal leaves nothing to return: the item fails, credits_used is 0, and you are not charged for an empty list.

The table #

OperationCreditsBecause
profiles/enrich1one profile fetch
profiles/enrich/detailed1, +0.5 per sectionone profile fetch, plus one per section at half each
profiles/activity41 profile + posts and reposts + comments + reactions
profiles/posts21 profile + 1 feed
profiles/comments21 profile + 1 feed
profiles/reactions21 profile + 1 feed
companies/enrich1one request, by slug or by id
posts/enrich1one request returns the post and its top comments
sales/search/people50 per request of 100 rows100 stubs, at half the credit a record costs
sales/search/companies50 per request of 100 rows100 stubs, at half the credit a record costs
sales/search/employees50 per request of 100 rowsthe same request, and a chunk that matched nobody is still one of them
sales/search/deep50 per request of 100 rowsthe same request again: a count is one and a page is one, so breaking a search past 2,500 rows carries no premium
find_emails (per person)+4a flat surcharge, on the operations that return a person
everything under /batches, /account, /usagefreereading what you already paid for is not work

activity is 4 rather than 6 because the profile is fetched once. Buying the three single-kind operations separately resolves it three times, and you would be paying for that.

find_emails is the one number on this page that is not derived from the rule above, because the thing it pays for is not a request to LinkedIn. It is a flat +4 per person we reach a verdict about, and it is flat on purpose: what a lookup actually costs depends on how quickly an address is found and on whether we already knew the employer, neither of which is anything you can see or plan around. A person we could not look up at all is free. See Finding email addresses.

What a credit costs #

A credit is a unit of work; what one costs in money falls with the size of the order, and the rate applies to the whole of it - $3 per 1,000 credits at the bottom, $1 per 1,000 at 1,000,000.

CreditsPer 1,000Cost
10,000$3$30
50,000$2.50$125
100,000$2$200
250,000$1.50$375
500,000$1.25$625
1,000,000$1$1,000

Credits are prepaid and they do not expire. There is no plan to be on, no renewal date and no overage charge: when they are gone, submissions answer 402 insufficient_credits rather than arriving as a bigger invoice, items already in flight finish with what they have, and nothing is queued behind them. Buy more and the next attempt runs.

GET /account reports what is left. Where credits have been bought it carries a quota.balance beside the monthly figures, and remaining is the smaller of the two - the one that will actually refuse the next request. Read balance for presence rather than for a value: it is absent, not zero, on an account that has never bought any.

Above 1,000,000 credits, and for the rate limits that go with any order, the number is agreed with us - see the pricing page.