open_linkedin_api.client.ChallengeException: CHALLENGE

[stickerdaniel]

Hey, I just tried your example code but I'm unable to log in.

[marekrost]

Addressed by: #3

[EseToni]

Hey @stickerdaniel, @marekrost,! The issue you're facing has been present since the library's original fork — the infamous "challenge" has been a recurring topic of discussion. There's a section in the README that covers all the findings and attempts to work around it so far.

From my experience, the most effective way to bypass it is by using session cookies instead of logging in with a username and password.

That said, I'm definitely interested in digging deeper into this and finding a more robust solution. Any insights or test cases you can share would be helpful!

[marekrost]

Hey @EseToni !

@stickerdaniel and I have synced up and aligned our use cases—there's definitely potential for synergy here.

Password-based authentication seems to be working well in my tests, though I haven't put much stress on the backend yet.

That said, I’ve run into some more serious issues. Specifically, certain API calls work for some content but fail for other content IDs of the same type. It almost feels like the REST API is being deprecated or becoming unreliable.

---

I’d like to contribute a few improvements to this repo to meet some immediate needs—and then kick off a full rewrite using GraphQL. This is now the primary way LinkedIn’s frontend communicates with the Voyager backend. Here are the key risks and considerations:

1. Query ID management – LinkedIn appears to use fairly static query IDs at the moment, which makes this manageable. We could extract them via an additional call to the frontend.

2. Schema discovery – Since there’s no official documentation, we’d need to reverse-engineer the GraphQL schema. I don’t see this as an insurmountable challenge: we can intercept GraphQL traffic in the browser, categorize the requests, and use an AI assistant to reconstruct known parts of the schema. I’ve already done a small test, and it looks promising.

3. Challenges / rate limits / account bans – These risks will exist regardless of whether we use REST or GraphQL, so we’ll need to factor in the usual precautions.

GraphQL is clearly the direction LinkedIn is taking for the foreseeable future—and I haven’t found any public project seriously investing in adapting to it. So why not be the first?

What do you think?

[marekrost]

To add my 2 cents on the challenge issue. I've tried my luck at scraping for a few years:

• The issue will never go away, companies of this size have the ability to deploy L7 firewalls and fine-tune them.
• This means that the parameters of who gets challenge evolve dynamically.
• This means that 3rd party tools (like this API client) will always need to be a a step ahead and slip through the cracks.
• This also means that the closer we can align our communication method to how LinkedIn.com frontend operates - the better, because it will appear more legitimite.
• Finally, the more we can make the community clump up behind a single project, the more resources we'll have to stay ahead. This is why I want to participate on something that is already here instead of starting from scratch again.

[EseToni]

Hey @marekrost, totally aligned with everything you said.

I also believe that shifting toward how LinkedIn’s frontend actually communicates — especially via GraphQL — is the most sustainable path forward. REST is getting increasingly unreliable, and from what I’ve seen, LinkedIn is doubling down on their GraphQL stack for all major features.

Personally, I’d love to start rewriting some of the current methods to make them more "pure" — in the sense that each method should do one job and return the most raw, unprocessed data possible. That would make it easier for consumers of the library to build exactly what they need on top, without having to untangle opinions baked into the client.

On a related note, I’ve been thinking about the long-term maintainability of the project. What are your thoughts on migrating the codebase to TypeScript? I think it could help with structure, readability, and community contributions — especially as things get more complex with GraphQL.

Would love to sync up more if you're up for it! thanks!!

[stickerdaniel]

I love the idea of moving the codebase to TypeScript for static typing and autocompletion. As for the authentication error, cookie-based authentication provides a better user experience overall (no sign-in emails or "verify login on LinkedIn mobile app") so I think it’s a good idea to set it as the default if that’s the method that works reliably

[marekrost]

I have no problem with switching the codebase to TypeScript. Just 3 points:

• We'd be abandoning the existing userbase of the API,
• I have low experience with TypeScript
• Since the project isn't using any exotic dependencies, and both languages are widely used - it's likely that we could convert it back and forth mostly automated with AI agent - fix and code review the rest.

Meaning I could just start the rewrite in Python where I'm more proficient and then we'd setup a secondary repo for TypeScript. Or vice versa.

[howfastcanyouace]

I have no problem with switching the codebase to TypeScript. Just 3 points:

* We'd be abandoning the existing userbase of the API,

* I have low experience with TypeScript

* Since the project isn't using any exotic dependencies, and both languages are widely used - it's likely that we could convert it back and forth mostly automated with AI agent - fix and code review the rest.

Meaning I could just start the rewrite in Python where I'm more proficient and then we'd setup a secondary repo for TypeScript. Or vice versa.

@marekrost, @EseToni Did you invest any more time into this?

I'm currently looking into how LinkedIn is using GraphQL. I found some basic examples using typescript on GitHub, but they all seem abandoned and used for basic scrapping only.

[marekrost]

@howfastcanyouace i've been stuck all summer with critical work projects, my schedule will likely free up enough in mid-october. At that point i will redo my research on current state of linkedin frontend - if they are phasing out the REST API, if they are still using static identifiers + recheck if anyone else has picked up this idea.

If you wanna participate or take charge, feel free to jump in.

From my point of view first step would be reverse-engineering the GraphQL schema for full feature set that we will need. All you gotta do is setup browser to monitor its network calls while you're using the website. Dump network log into files and instruct AI to reconstruct the API and schema structure. I've tried about 3 endpoints before summer and it seemed feasible.