Pipedrive Link Click Tracking: Deals From Short Link Hits

Pipedrive link click tracking in Elido turns short link milestones into pipeline events. When one of your links crosses 100, 1,000, or 10,000 clicks, a 5 minute cron creates a deal in the Pipedrive pipeline and stage you picked, with the link slug, the UTM source, and a deep link back into Elido in the deal notes. No Zapier in the middle, no manual export, no calendar reminder to check link reports.

That is the headline. The mechanics matter more, so this post walks through the three things sales ops teams need to trust before flipping this on. First, how the Connect flow actually works: where the Personal API token lives, what the pipeline picker is reading, and how the token is stored after you paste it. Second, what the threshold cron does on every run and how it avoids creating duplicate deals when a link goes viral overnight. Third, how to extend the integration past the three default thresholds, into custom click counts, UTM scoped triggers, and custom Pipedrive fields, using the Elido SDK and a tiny webhook handler.

Pipedrive went Live for Elido on 22 May 2026. Before then it sat in Beta for two weeks while we shook out edge cases around stage IDs and token rotation. The integration code lives in services/api-core/internal/integrations/pipedrive/ if you self-host and want to read the source. Everything in this post matches what is shipped, not a roadmap.

Connecting Pipedrive in Two Minutes#

Open the integrations catalog in your Elido workspace and click the Pipedrive card. The Connect modal asks for one thing first: a Personal API token. You get it from your Pipedrive account by opening your profile menu, choosing Personal preferences, then the API tab. Pipedrive's own guide on how to find the Personal API token has the exact path with screenshots, since their UI shifts every quarter or so.

Paste the token. Elido does two things in the background. It validates the token by calling GET /users/me against the Pipedrive API, which confirms the token is live and tells us which Pipedrive company the token belongs to. It also pulls the list of pipelines and stages for that company, so the next step in the modal shows real options, not free text fields.

The modal then asks two more questions. Which pipeline should new deals land in? Which stage in that pipeline? The dropdowns are populated from your live Pipedrive data. If you have three pipelines named Inbound, Outbound, and Partners, you see those three. Pick the one that fits the work, usually Inbound for marketing driven signals, then pick the first qualifying stage. Click Connect.

What happens to the token after Connect. Elido encrypts it before it touches Postgres, using envelope encryption with a per-tenant data encryption key wrapped by a workspace KMS key. The wrapped blob is what sits in the integration_credentials table. The plaintext token only exists in memory for the lifetime of a single API call, and we never log it, even at debug verbosity. If you rotate the token in Pipedrive, the next cron run gets a 401 and Elido marks the integration as needing reauth, which surfaces as a banner in the workspace, not a silent failure. Rotation hygiene is on you, the breakage is loud.

The pipeline picker is a small but important detail. A common failure mode in CRM integrations is creating deals in the wrong pipeline because the integration was built when the company had one pipeline and now has six. Letting the user pick at Connect, and showing the current list rather than caching one from a month ago, removes that whole class of mistake. You can also reconnect at any time to change the picker target without losing the threshold history.

What the 5 Minute Cron Actually Does#

Inside services/api-core there is a job called click_threshold_hook. It runs every five minutes. On each tick it does three things in order, per workspace that has Pipedrive connected.

First, it asks ClickHouse for the per-link click totals updated in the last six minutes, plus a buffer of one minute to cover late events. ClickHouse holds the click events in a clicks table partitioned by date, and the rollup we query is a materialised view keyed by short link ID. The query returns links whose totals changed since the last cron run, not the full table. On a workspace with 50,000 active links and a normal click pattern, this query stays under 200ms.

Second, it diffs each link's new total against the recorded thresholds. The default thresholds are 100, 1,000, and 10,000. For each link, Elido tracks the highest threshold ever reached in a tiny link_threshold_state row keyed by link ID. If a link sat at 80 clicks last run and is now at 240, the diff shows the 100 threshold was crossed and the 1,000 has not been touched yet. We mark 100 as reached and queue one deal creation. If a link jumped from 80 to 1,200, both 100 and 1,000 were crossed, so we queue two creations.

Third, for each queued deal, Elido calls Pipedrive's Deals API with a POST to /deals. The body sets the pipeline ID and stage ID from the Connect picker, names the deal something readable like Link <slug> hit <threshold> clicks, and writes the UTM source, medium, and campaign into the deal note along with a clickable link back to the Elido analytics view for that link. We also stash the link ID into a Pipedrive custom field if the workspace has one configured, which makes it possible to query Pipedrive for all deals tied to a specific Elido link later.

A few things this cron does not do. It does not retry indefinitely on Pipedrive 5xx. If Pipedrive returns 500 or 503, we retry twice with exponential backoff inside the same cron tick, then leave the work for the next tick. Pipedrive's rate limit is 100 requests per 2 seconds per company token in practice, which is plenty of headroom for the kinds of volumes most teams will hit. We also do not create deals for links flagged as test, internal, or owned by a workspace member who has opted out of CRM sync through their personal settings.

The duplicate prevention is the part that took the most iteration. The first version had a race: if two cron pods ran in overlap, both could see the same link cross 100 and both could POST a deal. We solved it with a Postgres advisory lock on the workspace ID at the start of each cron tick, plus a unique constraint on (link_id, threshold) in link_threshold_state. If the second pod tries to insert a duplicate row, Postgres rejects it, and the queued POST is dropped before it reaches Pipedrive. Belt and braces.

Extending Beyond the Three Defaults#

The shipped thresholds are 100, 1,000, and 10,000. Most teams keep those because they map naturally to a sales narrative. A hundred clicks is a soft signal worth a glance. A thousand is a campaign worth a call. Ten thousand is hot enough that a rep should already be moving. That said, you may want different numbers, and the SDK supports it.

The Elido Pipedrive integration accepts a custom threshold list at the workspace level. You set it through the PATCH /v1/workspaces/:id/integrations/pipedrive endpoint with a JSON body like {"thresholds": [50, 500, 5000, 50000]}. The cron picks up the new list on the next tick. The state table preserves history, so changing thresholds does not retroactively backfill deals, it only changes which future crossings fire.

For richer triggers, the SDK exposes a CreateDeal hook you can register from any service. The classic case: only create a deal when a link crosses a threshold AND the UTM source is your paid social campaign, not your organic blog. That is a one line filter inside the hook. Another common one: only fire on links inside a specific Elido folder, because that folder is your campaign folder and everything else is noise. The same hook can also set Pipedrive custom fields like Deal Source, Lead Channel, or whatever taxonomy your sales ops team uses. The conversion forwarding guide covers the same hook pattern for ad platforms, the Pipedrive case is structurally identical.

A note on custom fields. The SDK accepts either the human label or the hashed API key Pipedrive uses internally. If you reference a label that does not exist on the connected company, the deal still gets created and the missing field is logged as a warning, never as an error. A missing custom field should not block a real sales signal.

Teams with many links per campaign sometimes want to roll up thresholds across a folder. Set aggregation: "folder" on the workspace integration config and the cron groups click totals by folder, then checks the sum. The deal names the folder and lists the top three contributing links in the notes.

Where the Token Lives and How to Rotate It#

A short section because it comes up in every security review. The Personal API token is encrypted at rest using AES-256-GCM with a per-tenant data encryption key. The DEK is itself wrapped by a workspace level key in our KMS, and only the api-core process can unwrap it. There is no clear-text token in any log, any backup, or any error trace. We tested this with a fault injection that forced a Pipedrive 401 mid request, and the error path scrubs the token from the response before it reaches Sentry.

To rotate: generate a new Personal API token in Pipedrive, revoke the old one, then paste the new one into the Elido Connect modal again. The integration validates the new token, swaps it in place, and the next cron tick uses it. If you forget to update Elido after revoking the old token, the next cron tick gets a 401 and the integration goes into a Needs Reauth state, visible as a yellow banner on the workspace dashboard. No silent dead tokens.

On self-host the KMS is pluggable: file-backed by default, swap in HashiCorp Vault or your cloud KMS. ADR-0036 covers the long form.

Where This Fits in a Wider Funnel#

Pipedrive deal triggers from clicks are one piece of a larger pattern. Click counts are a leading indicator, not a revenue number, so you usually want them to flow into a CRM where the rest of the sales context lives. The deal is the handoff: marketing has done its job, sales picks it up. From there your normal Pipedrive workflows take over: assigning the deal to a rep, scoring it, moving it through stages, closing it.

If you are also forwarding conversions to ad platforms, the same click data feeds both flows. The conversion tracking feature handles the ad side, the Pipedrive integration handles the CRM side, and the two never fight over the same event. We see this combination most often on the marketers solution page, where the entire stack is paid acquisition into branded links into a CRM funnel.

For analysts who want to keep their numbers honest, two earlier posts cover the upstream concerns. Short link analytics: what to measure covers which click metrics actually correlate with revenue, and Track UTM end to end covers the UTM hygiene that makes the deal notes useful instead of noisy. Both pair well with this integration, since the deal Pipedrive creates is only as useful as the UTM data it carries.

One last detail on plans. The Pipedrive integration is on every paid Elido tier, and the 14 day trial includes it so you can prove out your threshold list before signing up. Free workspaces can create the connection for testing, but the cron does not fire for free links. The pricing page has the per-tier breakdown.

Setup Checklist#

Print this, do it once.

1. In Pipedrive: profile menu, Personal preferences, API tab, copy the token.
2. In Elido: Integrations, Pipedrive card, Connect.
3. Paste the token. Wait for validation.
4. Pick the pipeline and stage. Default to Inbound and the first qualifying stage.
5. Click Connect.
6. Optional: edit the threshold list if 100/1k/10k does not match your sales motion.
7. Optional: register a custom CreateDeal hook for UTM filters or folder rollups.
8. Wait five minutes. Send some test clicks. Watch the first deal land.

That is it. If you self-host, you also want to verify the cron is enabled by checking kubectl get cronjob api-core-click-threshold-hook returns a healthy schedule. On Elido Cloud the cron is managed for you.