Proxy Support for LinkedIn Integration
J
John
I believe the LinkedIn account IP is in one location, and when the cookie is used by your servers on Sendspark, it is done from a different location (and IP address). I think the only stable fix will be if you could provide your service with the ability to use a Proxy (IP) for each client. This way, when your server uses the cookie to visit LinkedIn, it uses the LinkedIn account from the same specified proxy. This would ensure a stable connection and prevent LinkedIn from blocking the integration.
A
Abe Dearmer
Hi John, thanks for the detailed write-up. To make sure we’re scoping the right solution, can you confirm a few specifics about your setup and what you’d need from proxy support?
1) What LinkedIn flow is breaking for you today (login, session/cookie validation, scraping/profile access, messaging, etc.), and what exact error or block are you seeing?
2) Are you using a single LinkedIn account per Sendspark workspace, or multiple accounts? If multiple, would you need a dedicated proxy per LinkedIn account, per user, or per workspace?
3) What type of proxy would you want to use?
- Residential vs datacenter
- Static IP vs rotating
- Country/city level targeting
4) How would you prefer to provide proxy credentials?
- Host:port + username/password
- IP allowlist
- SOCKS5 vs HTTP(S)
5) Do you need the proxy applied only to LinkedIn requests, or to all outbound traffic from Sendspark related to the integration?
6) Any compliance or security requirements on your side (for example, storing proxy credentials, encryption requirements, audit logs, or the ability to rotate credentials)?
If you can share the above plus an example of when it fails (timestamp, what action you took, and the LinkedIn account region), we can better evaluate whether per-client proxy routing is the right fix, and what an initial implementation would look like (MVP vs full proxy management).