![Network Linkedin batch Connection requests avatar](https://images.apifyusercontent.com/_wtAnfLgG9AUHKdkjX0w3by8XdgRNMDNzqA_DgpT_Fg/rs:fill:250:250/aHR0cHM6Ly9hcGlmeS1pbWFnZS11cGxvYWRzLXByb2QuczMudXMtZWFzdC0xLmFtYXpvbmF3cy5jb20vNEx2UlQ1R04zcmhINlFtWTUvNWdkSlBaUXVQd1lHb0ZZS24tbGlua2VkaW4taWNvbi0yNTZ4MjU2LTZ5cWFrbTdsLnBuZw.webp)
3 days trial then $20.00/month - No credit card required now
![Network Linkedin batch Connection requests](https://images.apifyusercontent.com/_wtAnfLgG9AUHKdkjX0w3by8XdgRNMDNzqA_DgpT_Fg/rs:fill:250:250/aHR0cHM6Ly9hcGlmeS1pbWFnZS11cGxvYWRzLXByb2QuczMudXMtZWFzdC0xLmFtYXpvbmF3cy5jb20vNEx2UlQ1R04zcmhINlFtWTUvNWdkSlBaUXVQd1lHb0ZZS24tbGlua2VkaW4taWNvbi0yNTZ4MjU2LTZ5cWFrbTdsLnBuZw.webp)
Network Linkedin batch Connection requests
3 days trial then $20.00/month - No credit card required now
SEND / REMOVE / LIST batch of linkedin connection requests. Recommended to call the actor once a day when ADDing. The script has a hard limit of 20 successfull connections requests per run. Linkedin has weekly limits setup (100-200) recommended usage: One run per day with 15-20 automated connection
[Feature request] Result with different status when invitation limit met
Closed
Would it be possible to respond with a different status than NOT_SENT when weekly connection limit is met? Today you get the same status when you already have pending connection to the user or already connected.
![saswave avatar](https://apify-image-uploads-prod.s3.amazonaws.com/qrKi4ttXGFHZMdpZp/MdQA3mAEv8fKySu6H-SASWAVE.png)
You mean in the list you provide, happens to send duplicates as input ? Could you send me a list of profile at dev@saswave.com so that we can make some tests and understand if we can differentiate an error (already in network / already sent vs weekly or daily limit)
Also do you have a list of status in mind ? (ex: sent, not_sent, already_sent, already_friends, error, limit_reached)
sourcegeek
I meant linkedin allows 100-200 connections a week, if you reach this limit your script responds with NOT_SENT status. There is no way to differentiate the reason for NOT_SENT.
![saswave avatar](https://apify-image-uploads-prod.s3.amazonaws.com/qrKi4ttXGFHZMdpZp/MdQA3mAEv8fKySu6H-SASWAVE.png)
As mentioned in the documentation, the first use case we implemented has a hard limit of 20 add connections request per actor run
So if your input contains a list with more than 20 url, only the first 20 successful connection request will be handled and the rest marked as not sent
So that you can schedule the actor to run every 1h and add 20 people (for exemple)
sourcegeek
I use your actor in cron jobs, not Apify UI. I schedule a connection in my systems, not apify. So I send only one request ever N hours. At some point weekly linkedin limit is reached. All I'm saying is that based on the output from the actor is not clear when that's the case.
![saswave avatar](https://apify-image-uploads-prod.s3.amazonaws.com/qrKi4ttXGFHZMdpZp/MdQA3mAEv8fKySu6H-SASWAVE.png)
Got it , will keep you posted on updates
![saswave avatar](https://apify-image-uploads-prod.s3.amazonaws.com/qrKi4ttXGFHZMdpZp/MdQA3mAEv8fKySu6H-SASWAVE.png)
We have updated the actor output results status : NOT_SENT, SENT, ALREADY_SENT, ALREADY_FRIEND, WEEKLY_LIMIT_EXCEEDED
Presence of NOT_SENT means you can call the actor again to send connections requests. It will be replaced with WEEKLY_LIMIT_EXCEEDED, meaning even if you call the actor again ,wont be possible to send connection requests yet
![saswave avatar](https://apify-image-uploads-prod.s3.amazonaws.com/qrKi4ttXGFHZMdpZp/MdQA3mAEv8fKySu6H-SASWAVE.png)
Would you need a feature to handle removing requests not being accepted in batches (with some kind of date filter) ?
sourcegeek
What a great support I really appreciate this! I'll test out new statuses.
sourcegeek
I would love to have an option to remove request yes! Personally I don't care about date filter since I do that myself in scheduled jobs within my system.
![saswave avatar](https://apify-image-uploads-prod.s3.amazonaws.com/qrKi4ttXGFHZMdpZp/MdQA3mAEv8fKySu6H-SASWAVE.png)
Will try to implement 2 use case for connection request removal:
- providing a list of profile and remove the connection request if still pending (no need for date filters)
- select a date filter (last 7 days, 2 weeks, 1month ...) and let the script get the list of requests still pending and remove according to the selected date filter
sourcegeek
Thanks a lot, I appreciate it!
![saswave avatar](https://apify-image-uploads-prod.s3.amazonaws.com/qrKi4ttXGFHZMdpZp/MdQA3mAEv8fKySu6H-SASWAVE.png)
We also added a feature to list all pending connections requests with linkedin url, title, name, numbers of days since request
All 3 features are ready to be shipped, we will work on updating the apify actor (documentation and input schema) this afternoon or tomorrow morning
Keeping you posted when you can try. We take any feedbacks :)
sourcegeek
That's awesome, thank you! Look forward
sourcegeek
Is it currently possible to use proxy with your actor?
![saswave avatar](https://apify-image-uploads-prod.s3.amazonaws.com/qrKi4ttXGFHZMdpZp/MdQA3mAEv8fKySu6H-SASWAVE.png)
Actor is up and running, proxy are not supported yet
sourcegeek
Thank you I'll take a look!
sourcegeek
Hey, I’m getting issues with latest build. Am I missing something in the input?
2024-06-03T07:40:05.142Z ACTOR: Pulling Docker image of build 1rZMb6zFMS9BLuwte from repository. 2024-06-03T07:40:05.676Z ACTOR: Creating Docker container. 2024-06-03T07:40:05.948Z ACTOR: Starting Docker container. 2024-06-03T07:40:08.645Z https://www.linkedin.com/in/ACwAAAHHOXcBxdtuFgwIycyHTd3RWHSE7S4UDxE/ 2024-06-03T07:40:11.803Z Traceback (most recent call last): 2024-06-03T07:40:11.806Z File "/usr/src/app/src/main.py", line 376, in main 2024-06-03T07:40:11.808Z raise err 2024-06-03T07:40:11.810Z File "/usr/src/app/src/main.py", line 370, in main 2024-06-03T07:40:11.813Z final = add_to_network(urls, cookies) 2024-06-03T07:40:11.815Z ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2024-06-03T07:40:11.817Z File "/usr/src/app/src/main.py", line 72, in add_to_network 2024-06-03T07:40:11.819Z raise Exception('Failed to retrieve target identifier. Refresh cookies session and try again.') 2024-06-03T07:40:11.822Z Exception: Failed to retrieve target identifier. Refresh cookies session and try again. 2024-06-03T07:40:11.824Z 2024-06-03T07:40:11.826Z During handling of the above exception, another exception occurred: 2024-06-03T07:40:11.828Z 2024-06-03T07:40:11.830Z Traceback (most recent call last): 2024-06-03T07:40:11.833Z File "
![saswave avatar](https://apify-image-uploads-prod.s3.amazonaws.com/qrKi4ttXGFHZMdpZp/MdQA3mAEv8fKySu6H-SASWAVE.png)
can you share the url of the run that failed
sourcegeek
![saswave avatar](https://apify-image-uploads-prod.s3.amazonaws.com/qrKi4ttXGFHZMdpZp/MdQA3mAEv8fKySu6H-SASWAVE.png)
Seems like a request failed because of cookies not being valid anymore , Did you try reset your cookies and retry the actor ? If the error still persists maybe we need to update the logic if linkedin has made some changes
sourcegeek
Here is another run that fails with valid cookie
https://console.apify.com/actors/20VDLIYjfHcsNe0nj/runs/sFSfZ9Y0zfCTAxHHo#log
sourcegeek
Failure is random, succeeds first time but then fails all following times
sourcegeek
It seems like it’s not failing for my cookie but for others. Is it possible that windows os cookies are different for some reason?
![saswave avatar](https://apify-image-uploads-prod.s3.amazonaws.com/qrKi4ttXGFHZMdpZp/MdQA3mAEv8fKySu6H-SASWAVE.png)
OS isn't be relevent for success, can you send me by mail at dev@saswave.com a copy of the cookies that fails (not sure if the ones in your last linkedin run are still valid)
sourcegeek
My guess with OS is that somehow cookie may contain OS metadata and when it detects different architecture windows/linux it asks for extra verification.
This cookie must still be valid.
One thing to note is that my cookie is fine (mac os) and works with all connection requests but of another user (windows) is not, it succeeds first time but following attempts fail.
I think it would really help to pass proxy configuration to your script. You think this wouldn’t make any difference?
- 7 monthly users
- 4 stars
- 39.8% runs succeeded
- 15 days response time
- Created in Nov 2023
- Modified 18 days ago