How to Send LinkedIn Invites From a Clay Table

Clay is excellent at building the row. It finds the prospect, enriches the title, layers in an intent signal, and catches a fresh job change. What Clay does not do is send the LinkedIn touch safely and tie the result back to the rep who owns the relationship. This Clay LinkedIn integration closes that gap: an HTTP column in your Clay table fires a connection invite or a direct message through Salescadia, which runs it on a rep's own connected LinkedIn account and logs the touch back to your CRM.

The split is clean. Clay enriches the row; Salescadia executes the LinkedIn touch and closes the loop back to the CRM. Keep your stack. We are the outbound execution and attribution layer.

Why route Clay LinkedIn sends through your reps' own accounts?

Because the alternative gets accounts restricted. The reason cold LinkedIn automation earns a bad name is that most tools blast from a shared pool or a burner, ignore per-account limits, and treat every profile as fair game. LinkedIn notices.

Every send Salescadia makes runs under one specific SDR's own connected LinkedIn account, never a shared one. That single design choice is what keeps sends inside LinkedIn's tolerance. Each account carries its own daily and weekly invite and message caps, and Salescadia throttles to whatever budget that rep has left rather than firing everything Clay hands it at once. If LinkedIn restricts a rep's account, that account's sends pause instantly (across Clay, the sequencer, and manual sends) until the rep reconnects. The org's do-not-contact list is honored on every call, so a suppressed prospect is a safe no-op instead of an awkward invite.

You control which rep sends by passing a sender_email on each row. Round-robin across the team, match by territory, or hand the send to whoever owns the account. Leave it blank and it falls back to the most recently connected account. The same routing works from any tool in Clay's integrations catalog that can post JSON, so a Zapier, Make, or n8n trigger reaches the identical endpoints.

How to send LinkedIn invites from a Clay table

Setup takes about five minutes and there is no marketplace app to wait on.

1. In Salescadia, open Settings → API keys → New key, name it "Clay", and grant the write scope. Copy the mm_live_... value, which you only see once.
2. Make sure at least one rep has connected their LinkedIn at Settings → Connections → Connect LinkedIn.
3. In your Clay table, add an HTTP API enrichment column. Set the method to POST, the URL to https://www.salescadia.com/api/v1/clay/linkedin/invite, and add two headers: Authorization: Bearer mm_live_YOUR_KEY_HERE and Content-Type: application/json.
4. Map your Clay columns into the JSON body. Clay substitutes any {{column}} token per row:

{
  "linkedin_url": "{{linkedin_url}}",
  "note": "Hey {{first_name}}, saw you're heading up growth at {{company}}. Mind connecting?",
  "sender_email": "{{account_owner_email}}"
}

That is the whole loop. When the column runs, Salescadia resolves the profile, checks the sender's caps and your do-not-contact list, sends the invite from that rep's account, and returns a flat JSON envelope so every field maps back to its own Clay column. Full step-by-step is in the help center guide.

What are the three endpoints?

All three share the same Authorization: Bearer mm_live_... auth and live on https://www.salescadia.com.

• POST /api/v1/clay/linkedin/invite sends one connection invitation with an optional note (up to 300 characters). This is the write call most Clay tables start with.
• POST /api/v1/clay/linkedin/message sends one direct message to a first-degree connection. It returns not_connected_yet if the prospect has not accepted the invite, so you chain this column behind an invite column that waits for acceptance.
• POST /api/v1/clay/linkedin/lookup resolves a profile URL to structured fields (name, headline, network distance) without sending anything. Use it as a read step to gate the invite and message columns to prospects who are actually eligible.

A clean cadence looks like: /lookup to filter the row set, /invite on the ones who are invite-eligible, then a scheduled run that calls /message once acceptance lands.

How does attribution survive when Clay does the triggering?

This is the part that separates a keep-your-stack integration from a script. Every touch Salescadia sends is written back as an outbound activity in your CRM, attributed to the rep who sent it and the campaign it belongs to. It shows up in that rep's own activity feed like any other outreach.

Acceptances, replies, and booked meetings are tracked natively through Unipile, not inferred from Clay. So the attribution holds no matter what Clay does next. Whether the table gets rebuilt, re-run, or archived, the meeting still ties to the right rep. Clay is the trigger; Salescadia is the system of record for the outcome.

Why does execution and attribution matter more than the send?

Because the send is the easy part, and it is not where deals are won or lost. The MedLeague case study measured a 30-point close-rate gap between the best and worst rep on the same team, working the same leads. That was 60.9% versus 30.6% across 2,420 meetings. When your outreach fires from a Clay table with no attribution, you cannot see which rep is turning connections into conversations and which is letting them go cold. The routing and the logged outcome are what make that visible.

That is why the integration is deliberately narrow. Clay owns the data and the waterfall. Your reps own the relationships and the accounts. Salescadia sits in the middle as the execution and attribution layer, so the send is safe and the result is measurable. If you are wiring up outbound across a team, the same logic sits behind our lead routing and the rest of the tools built for sales teams.

If you already run Clay, create a write-scoped API key in your Salescadia settings, add one HTTP column, and send your first invite from a row today. The touch lands under the right rep, and the reply comes back to the same place.