Webhooks

Event reference

Every event Curviate can deliver to your webhook endpoint, grouped by source. All are Core-tier unless noted.

Quick reference

The Availability column marks how an event is delivered. Events with no marker are delivered in real time. See Delivery availability below for the full meaning of each marker.

Early access — latency & directionality

The Availability markers below — and the inbound-only direction note on the message.* events — reflect the current platform substrate and are an early surface. The event names, sources, and payload envelope are stable and safe to build against; the exact latency labels and directionality are refined as live validation completes.

EventSourceAvailabilityDescription
message.receivedmessagingReal-timeAn inbound message arrived in any chat (classic message or InMail).
message.deliveredmessagingReal-timeAn outbound message was delivered.
message.readmessagingReal-timeA message in a chat was read by the recipient.
message.reactionmessagingReal-timeA reaction was added to a message.
message.editedmessagingReal-timeA message was edited after send.
message.deletedmessagingReal-timeA message was deleted.
chat.updatedmessagingReal-time · opt-inA chat's container state changed (e.g. archived, muted, read-state) — useful for inbox automation.
chat.deletedmessagingReal-time · opt-inA chat thread was deleted.
connection.acceptedusernot_realtime (~8h)A pending invitation was accepted by the recipient (a new relation).
connection.newusernot_realtime (~4h) · opt-inAny new relation appeared on the account — not just ones you invited.
account.createdaccount_statusReal-timeA new account link completed successfully for the first time.
account.connectedaccount_statusReal-timeThe account health check reported a healthy, connected state.
account.syncedaccount_statusno_longer_realtimeA synchronization cycle completed successfully.
account.reconnectedaccount_statusReal-timeAn existing account was re-authorized in place (credentials refreshed).
account.reconnect_neededaccount_statusReal-timeCredentials expired or the session cookie was invalidated — the account needs reconnection.
account.creation_failedaccount_statusno_longer_realtimeThe initial account-link attempt failed before completion (terminal).
account.disconnectedaccount_statusReal-timeThe account was removed from the platform (terminal state).
account.erroraccount_statusReal-timeAccount synchronization encountered an error (needs investigation — not a credentials issue).
account.pausedaccount_statusReal-timeAccount synchronization was stopped or paused externally. Not an error — may resume automatically.
account.connectingaccount_statusno_longer_realtimeAn account link is in progress (transient, high-frequency).
account.permission_revokedaccount_statusno_longer_realtimeA LinkedIn-side scope or permission the account relies on was withdrawn.
account.initial_sync.runningaccount_statusReal-time · opt-inThe initial history backfill for a newly connected account has started (informational).
account.initial_sync.completedaccount_statusReal-time · opt-inThe initial history backfill completed — full LinkedIn history is now queryable.
account.initial_sync.failedaccount_statusReal-time · opt-inThe initial history backfill failed — the delivery carries a neutral reason.

Delivery availability

GET /v1/webhooks/events returns an availability field on the events that are not delivered in real time. Three values are possible:

ValueMeaning
omitted, or realtime

Delivered in real time (the default). Most events omit the field; the three account.initial_sync.* events carry realtime explicitly.

not_realtime

The event is delivered, but on a poll delay (hours, not seconds). Do not build latency-sensitive logic on it. Applies to connection.accepted and connection.new.

no_longer_realtime

The event is no longer delivered on the current platform. Use the read-path alternative named in the event's description — for most, an on-demand account read via GET /v1/accounts/{account_id}. Applies to account.synced, account.creation_failed, account.connecting, and account.permission_revoked.

Default and opt-in events

When you create a webhook without an events array, it subscribes to that source's default set. Any event listed for the source can also be subscribed explicitly.

SourceDefault events (when events is omitted)
messagingmessage.received
userconnection.accepted
account_statusthe 11 lifecycle events (not the three account.initial_sync.*)
Opt-in only

chat.updated, chat.deleted, connection.new, and the three account.initial_sync.* events are never auto-subscribed. To receive them, name them explicitly in the events array when creating (or updating) the webhook.

Payload structure

Every delivery shares the same outer envelope:

{
  "id":           "wdl_YOUR_DELIVERY_ID",
  "webhook_id":   "wh_YOUR_WEBHOOK_ID",
  "event":        "message.received",
  "data": {
    "account_id":  "acc_YOUR_ACCOUNT_ID",
    "chat_id":     "chat_YOUR_CHAT_ID",
    "message_id":  "msg_YOUR_MESSAGE_ID",
    "text":        "Hello, how can I help?",
    "sender": {
      "name":        "Alex Jordan",
      "profile_url": "https://www.linkedin.com/in/alexjordan",
      "provider_id": "urn:li:member:123456789"
    },
    "attachments": [],
    "occurred_at": "2026-05-28T09:15:00.000Z"
  },
  "delivered_at": "2026-05-28T09:15:01.234Z"
}

id is the delivery ID (wdl_…); webhook_id (wh_…) references the webhook. data.account_id is present on every delivery.

Content-bearing payloads

Content events — the messaging message.* events and the connection.* events — carry the event's content directly in data (text, sender, and attachments for messaging; the new contact's profile fields for connections), so your handler receives everything it needs in one delivery. Structural events — the account-status lifecycle events and account.initial_sync.* — carry account state only, not LinkedIn content. See the per-source articles for the full payload shape.

Messaging events

Messaging events notify your endpoint whenever a message or chat changes state on a connected account. The message.* payloads include the full message content; the chat.* events describe a chat thread rather than a single message.

message.received

Fired when an inbound message arrives in any chat — classic LinkedIn messages or InMail. Fires for inbound messages only; a message the account sent does not fire it (use message.delivered for outbound confirmation).

message.delivered

Fired when an outbound message was delivered. Use it to close the send loop in fire-and-forget agent patterns.

message.read

Fired when a message in a chat was read by the recipient. The payload may include reader identity where available.

message.reaction

Fired when a reaction is added to a message. The data object includes a reaction field with the reaction value.

message.edited

Fired when a message is edited after send. The text field carries the post-edit content.

message.deleted

Fired when a message is deleted. The text field may be absent.

chat.updated

Fired when a chat's container state changed — for example archived, muted, or read-state. Useful for inbox automation. chat.updated is opt-in — name it in events[] to receive it. See the Messaging events article for the delivered data shape.

chat.deleted

Fired when a chat thread was deleted. chat.deleted is opt-in — name it in events[] to receive it.

User events

connection.accepted

Fired when a pending invitation you sent was accepted by the recipient. Once received, the two members are connected and messaging is available without InMail credits.

connection.new

Fired when any new relation appears on the account — not just ones you invited, so it is a superset of connection.accepted. connection.new is opt-in — name it in events[] to receive it.

User events are polled — not real-time

Both user events carry availability: "not_realtime": LinkedIn relationship state is polled on a schedule, so delivery lags the real event. connection.accepted may arrive up to ~8 hours after the recipient accepts; connection.new up to ~4 hours after the relation appears. A freshly connected account may also receive a backfill burst of connection.new events for its pre-existing network during the initial-sync window. This is a platform polling constraint, not a Curviate bug — design for the delay and for volume tolerance.

Account status events

Account events track the lifecycle of connected LinkedIn accounts — from creation through session expiry and eventual removal.

account.error vs account.paused

account.error means synchronization halted due to an error (needs investigation — not a credentials issue). account.paused means synchronization was stopped or paused externally — not an error, and it may resume automatically. Treat them differently in your handler.

Four events are no longer delivered

account.synced, account.creation_failed, account.connecting, and account.permission_revoked carry availability: "no_longer_realtime" — they are not delivered on the current platform. For account.creation_failed and account.permission_revoked, detect the state via an on-demand account read (GET /v1/accounts/{account_id}). For account.synced and account.connecting there is no equivalent event and no direct read-path signal.

account.created

Fired when a new account link completes successfully for the first time — the initial connect path.

account.connected

Fired when a health check confirms the account is in a healthy, connected state.

account.synced · no_longer_realtime

Historically fired when a synchronization cycle completed. No longer delivered on the current platform, and there is no equivalent event or read-path — do not build on it.

account.reconnected

Fired when an existing account was re-authorized in place — credentials refreshed without creating a new account ID.

account.reconnect_needed

Fired when credentials expire or the session cookie is invalidated. The account remains in your workspace but is inactive until re-authentication. Trigger a reconnect flow from the dashboard or call POST /v1/auth/intent with the account's account_id in the body to re-authenticate it in place.

account.creation_failed · no_longer_realtime

The initial account-link attempt failed before completion (terminal — no account was established). No longer delivered — detect via an on-demand account read (GET /v1/accounts/{account_id}).

account.disconnected

Fired when the account was removed from the platform (terminal — deletion or disconnect). The account ID is no longer valid and any webhooks scoped to it stop delivering.

account.error

Fired when account synchronization encountered an error (needs investigation — not a credentials issue).

account.paused

Fired when account synchronization was stopped or paused externally — not an error, and it may resume automatically.

account.connecting · no_longer_realtime

Historically a transient, high-frequency event fired while an account link was in progress. No longer delivered on the current platform. Detect link-in-progress via the account read (GET /v1/accounts/{account_id}) instead.

account.permission_revoked · no_longer_realtime

A LinkedIn-side scope or permission the account relies on was withdrawn. No longer delivered — detect via an on-demand account read (GET /v1/accounts/{account_id}).

account.initial_sync.running · account.initial_sync.completed · account.initial_sync.failed

The initial history backfill for a newly connected account is bracketed by these three opt-in events: exactly one account.initial_sync.running (informational), followed by exactly one of account.initial_sync.completed (the actionable signal — full LinkedIn history is now queryable) or account.initial_sync.failed. The failed delivery carries a neutral reason — one of internal, proxy, or provider. See the Account status events article for the full treatment.

COMPANY · LEGAL

Privacy Policy

Redmer Holding GmbHLast updated July 25, 2026

Who we are

Curviate is operated by Redmer Holding GmbH ("Curviate", "we", "us"), a German GmbH registered at Amtsgericht Bonn, HRB 29957, registered address Hostertstraße 16, 53332 Bornheim, Germany. Full company details are on our Imprint. We haven't appointed a statutory Data Protection Officer, since our processing doesn't reach the scale or sensitivity that requires one. Privacy questions go to privacy@curviate.com.

The two roles we play

When you create an account and use Curviate, we process your own data (identity, billing, API keys, connector authorizations). For that data, we are the controller.

When you use Curviate to act on your own connected LinkedIn account, viewing profiles, sending messages, managing engagement, that content and those contacts belong to that account and its people. You are the controller of that data; we are the processor, acting only on your instructions, under the Data Processing Agreement between us. If one of your contacts has a question about being reached through Curviate, you're who they should contact first; email privacy@curviate.com if you need help routing it.

What we collect, and why

DataWhy
Account identity (name, email, sign-in method)Create and secure your account
Your LinkedIn credentialsOperate the actions you request
LinkedIn content returned by an API callFulfil that specific request, nothing more
API keys and connector (OAuth) authorizationsAuthenticate your API, CLI, MCP, or SDK requests
Billing detailsCharge you correctly and meet our tax obligations
Usage and security logsKeep the service reliable and abuse-free
Support messagesRespond to you
Website analytics, only if you opt inUnderstand how the site is used

We rely on our contract with you, our legitimate interest in running and securing the service, our legal obligations (tax law, for example), and, for analytics, your consent. We never sell your data or use it to train models.

Where it's processed, and who else touches it

Our infrastructure runs in the EU. Hosting: Railway. Database and auth: Supabase, Ireland. Email: Resend. Payments: Stripe. Network security: a DDoS-protection provider sits in front of our app and never sees or stores request content. LinkedIn connectivity: a third-party infrastructure provider that lets us execute LinkedIn actions on your behalf. Error tracking: Sentry, Frankfurt. Product analytics: PostHog, Frankfurt. Uptime monitoring: Better Stack.

We give the current, named list of every provider above, plus our Data Processing Agreement, to any customer who asks: security@curviate.com.

Outside the EU

All customer LinkedIn data, account data, and telemetry are processed and stored exclusively in EU regions of our sub-processors. A few providers we rely on (Stripe and Sentry, for example) are headquartered outside the EU/EEA; where that applies, it's covered by their own GDPR safeguards, typically the EU Standard Contractual Clauses.

How long we keep it

DataRetention
Account and workspace dataWhile your account is active
Closed accountRecoverable for 7 days, then deleted on day 8
LinkedIn credentialsUntil you disconnect that account
LinkedIn contentNot stored; any transient cache clears within 1 hour, never indexed, never used for training
API keysUntil you revoke or rotate them
Connector (OAuth) authorizationsAccess token ~1 hour; refresh token up to ~12 months, or until you revoke it, whichever comes first
Billing recordsAs required by German tax law, currently up to 10 years
LogsA short operational window; metadata only, never message content

The 12-month figure above is a server-side credential for a connected AI agent or app. It is not a cookie and doesn't touch your browser session; see Cookies below for that. You can see and revoke every connector from Authorized applications in your dashboard at any time.

Cookies

We keep cookies to a minimum, and ask before anything beyond the essentials runs.

Strictly necessary, no consent needed:

NamePurposeExpiry
cc_cookieRemembers your cookie choice12 months
curviate-themeRemembers light/dark mode (local storage, not a cookie)Persistent
sb-*-auth-tokenKeeps you signed inWhile active; cleared on sign-out

Analytics, only if you accept:

NamePurposeExpiry
_gaGoogle Analytics: distinguishes visitors2 years
_gidGoogle Analytics: distinguishes visitors24 hours
_ga_<container id>Google Analytics: persists session state2 years

No advertising cookies, ever. Accept and reject are equally easy, and you can change your mind any time via Cookie Preferences in the footer; we won't ask again for 12 months unless something material changes. Our LinkedIn connect flow and OAuth authorization screen never set anything beyond the essentials, so no banner appears there.

Connecting an AI agent or app

Curviate is built for AI agents and automated clients as much as for people. If you connect an app like Claude, or your own code, via an API key or an OAuth connector, it can act on your workspace within the access you gave it. What it does with anything it receives back, including what it sends to its own AI model, is between you and that provider; review its practices before connecting it. Review and revoke any connection any time from your dashboard.

Your rights

You can access, correct, delete, restrict, or object to your data, port it elsewhere, and withdraw consent at any time: email privacy@curviate.com. Closing your account starts the 7-day recoverable window above. We don't make automated decisions about you that have a legal or similarly significant effect. You can also complain to a supervisory authority; ours is the Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen (LDI NRW), www.ldi.nrw.de, though you're free to complain to the one in your own country instead.

Keeping it secure

Credentials are encrypted and never logged, returned, or shared. LinkedIn actions run through native, humanized flows; full detail is on our Security & Compliance page. If a breach puts your rights at risk, we'll notify the authorities and you, as GDPR requires. Curviate isn't directed at, or offered to, anyone under 16.

Changes

We'll update this page when our practices change, and reset the cookie prompt if the change is material.

Contact