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 #
| Operation | Credits | Because |
|---|---|---|
| profiles/enrich | 1 | one profile fetch |
| profiles/enrich/detailed | 1, +0.5 per section | one profile fetch, plus one per section at half each |
| profiles/activity | 4 | 1 profile + posts and reposts + comments + reactions |
| profiles/posts | 2 | 1 profile + 1 feed |
| profiles/comments | 2 | 1 profile + 1 feed |
| profiles/reactions | 2 | 1 profile + 1 feed |
| companies/enrich | 1 | one request, by slug or by id |
| posts/enrich | 1 | one request returns the post and its top comments |
| sales/search/people | 50 per request of 100 rows | 100 stubs, at half the credit a record costs |
| sales/search/companies | 50 per request of 100 rows | 100 stubs, at half the credit a record costs |
| sales/search/employees | 50 per request of 100 rows | the same request, and a chunk that matched nobody is still one of them |
| sales/search/deep | 50 per request of 100 rows | the 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) | +4 | a flat surcharge, on the operations that return a person |
| everything under /batches, /account, /usage | free | reading 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.
| Credits | Per 1,000 | Cost |
|---|---|---|
| 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.