Iridium vs. Unipile

Short answer: these are not the same kind of thing, and the honest version is that Iridium runs on Unipile. Unipile sells excellent developer infrastructure for messaging. It is the layer, and you build the product. If the product you would build is a LinkedIn inbox for your own agent, that product already exists.

What each one sells

Unipile is direct about its audience. Its docs say it exists to "provide seamless integrations of various messaging and communication channels into your software applications" and to help you "avoid the complexities of building messaging functionality from scratch". The marketing line is "One API for Multi-Channel Messaging in your app", and the proof point is "Trusted by 4,000+ SaaS Platforms".

Read that as written. The customer is a company with an app. The API is one component of that app. Unipile is very good at being that component, which is why it is the connectivity layer underneath Iridium.

The comparison people actually mean is between two paths to the same outcome. Path one is Unipile plus the software you write. Path two is software someone already wrote on Unipile.

Price, side by side

Both trials are genuinely card-free, which is worth saying plainly. The gap is not the trial. It is that €49 plus VAT is the price of a component, and $20 is the price of a finished thing.

The MCP server question

Unipile publishes an MCP server, so the natural assumption is that connecting it to Claude gives you LinkedIn tools. It does not work that way.

The server exposes five tools, and none of them is LinkedIn-specific:

This is an OpenAPI explorer, and as an OpenAPI explorer it is well made. It is aimed at a developer poking at the API from inside an editor. Sending a LinkedIn DM through it means hand-constructing the request and passing it to the generic execute-request tool. There is no "reply to this thread" tool, because tools like that are the product you were going to build.

Getting there also has a setup shape worth knowing in advance. You create an account, get your DSN, generate a token, connect accounts, and pass the DSN plus an X-API-KEY header on every request. Hosted authentication has to be proxied, and Unipile's docs say a backend process of your own is required to make that call. That is correct engineering advice. It is also a backend you now run.

The list you write yourself

This is the real comparison. Below is what sits between a Unipile API key and a working LinkedIn assistant, with a note on where each piece comes from today.

Nothing in that column is a flaw. A platform serving 4,000 SaaS companies should not be opinionated about your approval queue. Every one of those companies wants a different one. The point is that the column exists, it is longer than it looks, and it does not stop needing attention after launch.

Limits are the part people underestimate

Unipile's rate-limiting documentation, verified September 2026, says: "We don't enforce any limits on our side, so you'll have the exact same limit in the LinkedIn UI." It then asks that you "ensure your system handles this error effectively". Quota management is listed as "Coming Soon".

That is the right design for infrastructure. The consequence is that the ceiling lives in your code, and if the ceiling lives in a prompt it is a suggestion rather than a ceiling. You find out it was a suggestion when the account is restricted.

You also learn about a breach after the fact. LinkedIn returns the error, your job fails, and the send is gone unless you wrote the retry.

Scheduling, in their words

Unipile's scheduling guidance is to "store all generated slots in your database", and it warns that "if a user initiates two sequences simultaneously, you should pause the first one". Both statements are accurate and both are instructions for you. Slot generation, persistence, collision handling and the worker that fires at the right minute are yours to write and yours to keep running.

Where Iridium fits

Iridium is the finished side of that list, running on Unipile for connectivity, at $20 a month for one LinkedIn account with a 7-day trial and no card.

The pieces that exist because someone already built them:

• Real LinkedIn tools. List and search chats with an operator grammar including is:unread, from:, company: and newer:7d. Separate the threads you are being ghosted on from the ones where you owe a reply. Summarize a thread down to the core ask and the suggested next step.
• Drafting with your own examples. draft_reply reads up to 30 messages of the thread and writes under 600 characters with no emojis and no exclamation marks, using three of your past messages as style examples.
• An approval queue. Every outgoing action is a draft. Approving is a separate call and it is the only thing that sends. There is no auto-approve mode anywhere in the product. Comment and post drafts refuse an unedited AI draft with a 422.
• Server-side limits. 25 comments a day, 25 outreach actions a day, and a rolling backstop of 90 invites per 7 days. These are enforced on the server, identically for the web app and the agent.
• Deferral instead of failure. Hit a cap and the send is moved to 09:30 the next day rather than dropped. Idempotency guards run before the external call, not after it.
• Scheduling that already exists. Sends are stored, listed, rescheduled and cancelled through tools. Nothing goes in your database.
• Retention that runs whether or not you do. Discovered profile and post data is purged after 7 days by a daily job, platform-wide.

Replies to existing threads are exempt from the daily cap, because answering someone who wrote to you creates no new connection.

When Unipile is the right answer

Buy Unipile directly when you are putting messaging inside a product other people use, when you need channels beyond LinkedIn, when you are linking accounts on behalf of customers, or when the exact behaviour of the queue and the limits is something you want to own. Those are the jobs it was built for and it does them well.

Buy Iridium when the LinkedIn inbox is the goal rather than the project.

Questions people ask next