LinkdAPI Overview

LinkdAPI is a credit-priced data API for professional profile, company, job and post records. You send an API key, it returns structured JSON, and no LinkedIn account is connected at any stage. That single design choice sets everything else about the product: what it can do, what it costs, what it puts at risk, and what it can never be asked to do.

What LinkdAPI is (not Linked API)

Two products in this category answer to almost the same name. LinkdAPI lives at linkdapi.com and sells professional data by the credit. Linked API lives at linkedapi.io, runs a dedicated cloud browser per connected account and sells actions by the seat. Different companies, different products, and the confusion is worth clearing before any comparison, because the two sit on opposite sides of the line that divides this category.

LinkdAPI describes itself on its homepage as “The best API for professional Data” and, one line down, as a “Powerful, lightweight B2B Data API for enriching professional profiles, companies, and more” with “enterprise-grade reliability”. The stated jobs are data enrichment, CRM hygiene and workflow automation. The documentation frames the same thing as “structured, reliable, and real-time information for analytics, CRM enrichment, and workflow automation”.

The name is changing. Since October 2026 linkdapi.com opens with a banner reading “LinkdAPI is now Renidly”, and signup goes to renidly.com, whose pricing page names the operator as Droven Data Strategy LLC and adds an Email API to “Verify, find, and resolve any work email”. The linkdapi.com docs, endpoints and header still answer, so this page keeps the name the API is called by.

The product is also listed on RapidAPI, where the same endpoints answer to an X-RapidAPI-Key header, so a buyer can reach it through a marketplace subscription or through the vendor directly.

How it works

The whole integration is one header. The documentation puts it plainly: “Include the following header in all your API requests: X-linkdapi-apikey: your_api_key_here”. Requests go to linkdapi.com over HTTPS, paths sit under /api/v1/, and the response is JSON. There is no OAuth step, no connected profile, no cookie to paste and no browser to keep open.

The vendor states the architecture in the negative on its homepage, in two fragments worth reading together: “No browser automation, no sessions”, and “direct data delivery optimized for throughput”. The terms name the input side: LinkdAPI “aggregates information from publicly accessible sources on the open web, including public profile pages, public company directories, public job listings, public articles, and other publicly available content”.

Three official SDKs wrap the same surface, in Python (with a synchronous and an asynchronous client), Node with TypeScript types, and Go. The Python package installs with pip install linkdapi and takes the key straight into the constructor.

What it reads

The marketing surface says “50+ endpoints” across “10+ data categories”. The documentation’s own cost page is more precise and slightly larger: 56 endpoints across 11 categories, each charged at a default of one credit per request.

The categories and the shape of each one, read off the endpoint reference and the Python SDK:

• Profile, 16 endpoints. The deepest part of the surface. Paths run from /api/v1/profile/overview and /api/v1/profile/full through contact info, full experience, certifications, education, skills, recommendations, interests, services, reactions and a “social matrix”, plus a username-to-urn resolver and a similar-profiles call.
• Companies. Name lookup, company info by id or name, similar companies, affiliated pages, employee data and the company’s own job listings.
• Jobs. A job search that takes keyword, location, geo id, company ids, job type, experience level, region, time posted, salary and work arrangement, then job details, similar jobs and a people-also-viewed call.
• Search, 6 endpoints. People, companies, posts, services and schools, each with its own filter set. People search takes current company, past company, school, title, industry, geo urn, profile language and first and last name.
• Posts, comments and articles. All posts for a profile with cursor paging, featured posts, post detail, post likes, post comments, comment likes, article lists, article detail and article reactions.
• Services, geos and lookups. Service detail by vanity name, similar services, and resolvers for geo names, industries, job functions, title skills and services, which exist so that a search filter can be built from a human string.

Two things about that list are worth saying out loud. It is wide on reading a person and reading a company, and it has nothing in it that writes. And the filters on the search endpoints mirror the ones a member sees in the product, which is what makes it usable for list building.

What it costs

Pricing is credits, bought in advance and spent per call. New accounts get 100 free credits with no card, and the FAQ commits to credits keeping their value: “API credits remain valid and never expire.” The default charge is one credit per request, so for most of the surface a credit is a call.

The published ladder prices credits by how many you hold. The last column is arithmetic on the vendor’s own rate, at one credit per call, so a reader can recompute it.

The ladder is steep at the bottom and flat at the top. Moving from Testing to Developer cuts the price of a call by about half, while the four steps from Scale to Strategic Partner move it by forty cents per thousand across a tenfold rise in balance. The two top tiers, Ultra and Strategic Partner, were added after our first read in September, when the printed ladder stopped at Business. The top one has no upper bound.

The pricing shape is worth naming because it is the one that travels with this kind of product. Cost tracks calls, so a workload that reads the same profile twice pays twice, and a job that pages through a large result set pays per page. Account-based APIs in the same category price per connected account with the actions unmetered, which inverts that arithmetic. Neither shape is cheaper in the abstract, and the crossover depends entirely on how many times a record gets read.

The rate limit that moves with your balance

This is the mechanic that separates LinkdAPI from most metered data APIs, and the vendor documents it clearly: your throughput is a function of how much credit you are holding. The account reference states it twice. “Your per-minute rate limit is tier-based and changes with your credit balance.” And then the consequence: “As you spend credits and move between tiers, your limit_per_minute moves with you.”

Read the table above again with that in mind. A pipeline sized against the Scale tier runs at 250 requests a minute while the balance sits above 100,000 credits. It runs at 150 the moment the balance falls through that line, and at 70 once it drops under 30,000. Nothing changed in the code and no plan was downgraded. The balance moved.

The vendor gives you the instrumentation to follow it. A tier endpoint at /api/i/v1/credits/tier/k/, authenticated with its own X-AUTHAPI-Key header, returns the current tier, its limit_per_minute and a next_tier.credits_needed field described as “Credits you need to add to reach the next tier”, while /api/i/v1/credits/balance/k/ returns the balance alone. The documentation also warns what happens if you ignore it: a client-side rate limiter with a hardcoded number drifts out of sync as soon as the balance crosses a tier boundary.

The published throughput figures do not agree with each other. Four surfaces, four numbers, re-read on 24 October 2026:

• The pricing table tops out at 550 requests a minute, on the Strategic Partner tier, which is the highest tier it prints.
• The homepage says “Tier-based rate limits up to 600 req/min”, and separately advertises “600+req/sec” of capacity, which is a different unit again.
• Renidly’s pricing page adds a Custom tier “up to 1,000 req/min”, with a $50 minimum top-up.
• The documentation’s own 429 example prints 25. Its sample error body reads “Too many requests for your tier \”Developer\”. You’ve reached the highest tier.”, with a current_limit of “25 requests/minute”, against the 70 the pricing page gives Developer.

Latency is published twice and disagrees the same way. The homepage claims “Sub-200ms responses” and “<500ms avg latency”. The documentation header carries “<2s” as the average response time. Uptime is stated once, at 99.9%, with a 99.99% target listed on the roadmap for Q2 2026.

The practical reading: treat the account endpoint as the source of truth for your own limit, and size a batch job against the tier your balance will be in when it finishes, which is a lower tier than the one it started in. Errors are conventional, 401 for a missing key, 404 for an unknown route and 429 for the tier ceiling.

What the vendor publishes about the data

There is no ban rate on this vendor’s pages, no account sample and no safety percentage, and for once that absence is structural. No LinkedIn account is connected, so the category does not apply in either direction. The account-safety axis is empty for LinkdAPI the way a channel-coverage axis is empty for a product with one channel.

What the terms do carry is a sourcing position, stated in the vendor’s own words. On the input: “We do not access, store, or distribute private, password-protected, or non-public data, and we do not bypass authentication or technical access controls of any third-party platform.” On affiliation: “We are not affiliated with, endorsed by, or sponsored by any third-party platform.” On the buyer’s obligations, the terms name data-protection law (GDPR, CCPA “and equivalent regimes”) and anti-spam law (CAN-SPAM, CASL, the GDPR direct-marketing rules) as the customer’s to satisfy.

One prohibition is unusual enough to flag for anyone building with a model in the loop. The terms forbid “Training, fine-tuning, or evaluating machine-learning models on data retrieved through the API without rights appropriate to that purpose”. Read it before you pipe enrichment output into a training set.

The service is offered “as is” and “as available” without warranties of any kind, which is standard for the shape and is also the sentence that matters most when the question is durability.

What you are building on

The risk on a dataset route sits with the provider, and this category has a worked example. LinkedIn filed suit against Proxycurl in January 2025, and Nubela announced the shutdown on 4 July 2025, taking 21 endpoints and every integration built on them with it. We wrote that story up in full in the Proxycurl overview. It is the reason provider durability belongs on the checklist for any credit-priced read API, LinkdAPI included.

LinkdAPI publishes a roadmap, and it dates the product’s history. The core profile API, contact information and the experience and education endpoints are marked shipped in Q3 2025. Posts, companies, search, jobs, articles and the rate-limiting system followed in Q4 2025. The Node and Go SDKs, multi-region infrastructure and a caching layer are marked Q1 2026. In progress for Q2 2026: an interactive API playground, a code examples repository and the 99.99% uptime target. Planned after that, a “Professional Data Database” with public release pencilled for September 2026, a GraphQL API in Q4 2026, and a 2027 line that talks about 100M+ profiles. The roadmap page itself is dated February 2026, so on 14 October 2026 the September date for the database had passed with no newer status on the page.

So the surface is roughly a year old, it has grown steadily on a published schedule, and the vendor is willing to date its own history. Weigh that against the fact that every read API of this shape depends on continued access to a source it does not own.

The shape of job it fits

LinkdAPI fits a narrow job well. You have a list of profile URLs or company names and you want them turned into structured records at volume, with one key, no onboarding and no account to protect. Enrichment into a CRM, list building from the search filters, job-market monitoring and post-level research all sit inside that job, and the credit model means you can size the spend before you start.

The edges follow from the same design. It reads and never writes, so outreach is out of scope. It has no view of a logged-in member’s own network, so first-degree connections, conversation history and anything that depends on who you are are out of scope too. Throughput is tied to your balance. And the data arrives from the vendor’s collection, so its freshness and its legal footing are the vendor’s to maintain and yours to accept.

Where a product needs LinkedIn actions as typed calls on accounts the customer owns, the category holds a different shape entirely: account-based APIs such as Unipile, Linked API, ConnectSafely.ai and gtm-api.com, which connect a real account server-side and expose invitations, messages and searches as endpoints with limits enforced before each call. On that stack, gtm-api.com runs 20,000+ accounts with under 1% of them ever restricted. The dividing question is simple enough to answer in one sentence: are you reading records, or acting as somebody?

Frequently Asked Questions

Sources & Further Reading

• Renidly, pricing (the rename, the operator, the Email API and the Custom tier), read 24 October 2026
• LinkdAPI, homepage (the “now Renidly” banner, the positioning lines, “50+ endpoints”, “10+ data categories”, the latency and throughput claims, and “No browser automation, no sessions”) · pricing (the nine tiers, credits per dollar, per-minute limits and the 100 free credits)
• LinkdAPI, documentation introduction (the X-linkdapi-apikey header, the RapidAPI route, the error codes and the 429 example) · account and credits (the balance endpoint, next_tier.credits_needed, and the rate limit that moves with the balance) · endpoint pricing (56 endpoints, 11 categories, one credit default)
• LinkdAPI, product roadmap (the dated history from Q3 2025 and the planned database, GraphQL API and uptime target) · terms of service (the sourcing statement, the non-affiliation line, the compliance obligations and the model-training prohibition)
• LinkdAPI, Python SDK and Go SDK (the method names behind each endpoint category)
• gtm-api.com, product · pricing (our own numbers)
• Related: Best LinkedIn API · Linked API overview · Proxycurl overview · LinkedIn profile data API · LinkedIn scraping vs a safe API

Michael SalamatovGTM engineerRuns the gtm-api.com blog. Covers LinkedIn limits, account health and the API side of outbound.in

Last updated: October 2026 · Definitions and benchmarks verified at time of publication