CONNECTIONS / PostgreSQL / PostgreSQL to LinkedIn Offline CAPI
Your PostgreSQL tables, wired to LinkedIn account-revenue reporting.
Signals reads your PostgreSQL tables through a read-only database user scoped to the PostgreSQL tables you name, then reports closed B2B deals so LinkedIn optimizes on account revenue so LinkedIn sees offline conversions without an export.
- ● postgresql → linkedin.capi :: live
- > read closed_deals rows=38,148
- hash sha256(email,phone) consent=filtered
- route linkedin deliver
- ✓ delivered · 29,755 matched
WHAT THIS ENABLES
PostgreSQL to LinkedIn Offline CAPI
LinkedIn Offline CAPI for PostgreSQL: Signals reports closed B2B deals so LinkedIn optimizes on account revenue straight from your PostgreSQL tables, hashed and consent-screened each time the read runs.
- Signals reports closed B2B deals so LinkedIn optimizes on account revenue, reading your PostgreSQL tables each time the read runs.
- Account revenue attached to the sourcing campaign, with no export step out of your PostgreSQL tables.
The click, the conversion, and the credit.
The conversion happens off LinkedIn, away from any pixel. Here is how PostgreSQL closes the loop.
Built for the teams that own the number.
Engineering teams running PostgreSQL who need pipeline revenue tied to the LinkedIn campaigns that sourced it out of PostgreSQL tables.
From kickoff to verified events.
-
Connect
A read-only database user scoped to the PostgreSQL tables you name, mapped to LinkedIn's Conversions API and tuned for long B2B attribution windows.
-
Map
Columns from your PostgreSQL tables align to LinkedIn's Conversions API in the visual mapper, hashed as the read runs and checked for long B2B attribution windows.
-
Deliver
Each time the read runs, Signals reads your PostgreSQL tables and reports closed B2B deals so LinkedIn optimizes on account revenue, reads only the records changed since the last run, with long B2B attribution windows watched in the debugger.
What changes when the CSV goes away.
| Capability | Manual CSV upload | Datahash |
|---|---|---|
| Reporting | Offline sales sit in a separate export, reconciled by hand. | Revenue counted in the same Offline CAPI reporting as web conversions. |
| Deduplication | A re-uploaded file risks counting the same conversion twice. | Deduped delivery, so a resent record never counts as a second conversion. |
| Match visibility | Match quality is a guess until the numbers look off. | Match rate reported per upload, tied to the source event set that produced it. |
| Effort and latency | An analyst exports and uploads on a manual cadence. | Server-side and automatic the moment PostgreSQL records the event. |
What Offline CAPI actually receives.
- ● signals :: event payload
- > POST /conversionEvents source=postgresql.closed_deals
- conversion "urn:lla:llaPartnerConversion:52496"
- conversionHappenedAt 1784793496000
- user.userIds [{ idType: "SHA256_EMAIL", idValue: "9c41af…" }]
- ✓ accepted · conversionValue 31575 USD
Adjacent moves on the same stack.
from PostgreSQL
PostgreSQL to Google OCI
Google Offline Conversions for PostgreSQL: Signals reconciles closed-won revenue to the…
Learn morefrom PostgreSQL
PostgreSQL to Google Store Sales
Google Store Sales for PostgreSQL: Signals matches in-person transactions to Google…
Learn moresame use case
ActiveCampaign to LinkedIn Offline CAPI
ActiveCampaign to LinkedIn Offline CAPI: Signals reads your ActiveCampaign contacts and…
Learn moregeneric
LinkedIn Offline CAPI
Datahash routes offline outcomes, like closed deals from your CRM, to LinkedIn with hashed…
Learn moreAsked on almost every call.
How often does the PostgreSQL LinkedIn Offline CAPI sync run?
Delivery tracks PostgreSQL, run by engineering teams running PostgreSQL: a near-real-time or scheduled sync of your PostgreSQL tables feeds LinkedIn on that cadence. Each run reads only the records changed since the last run, so account revenue attached to the sourcing campaign holds up on long B2B attribution windows. The live debugger confirms every delivery inline.
What match rate should a PostgreSQL-sourced LinkedIn Offline CAPI batch expect?
Coverage of hashed identifiers across your PostgreSQL tables decides it, and engineering teams running PostgreSQL own that inside PostgreSQL. A live email or phone matches into LinkedIn; neither, and it will not. First-run feedback flags long B2B attribution windows, which engineering teams running PostgreSQL then raise inside your PostgreSQL tables.
NEXT STEP