---
title: "Relation New Webhook"
method: POST
path: "/api/v1/webhooks/unipile/relation-new"
tags: ["webhooks"]
---

# Relation New Webhook

`POST /api/v1/webhooks/unipile/relation-new`

## Request

- Base URL: `https://api.nudgelink.co` (the document declares no server; this is the origin it was published from)
- URL: `https://api.nudgelink.co/api/v1/webhooks/unipile/relation-new`
- Auth: none declared

Unipile ``new_relation`` (v1) / ``relation.new`` (v2): a connection was
accepted. Stamps ``invite_accepted_at`` on any matching waiting sequence.

Why this exists (need.md §3.2/§3.3): today acceptance is detected by the DM
gate spending a real profile view per waiting lead per day — roughly 200/day
on a busy seat against a 120/day budget that ONLY discovery reads and is
never blocked by, so the failure is silent: discovery stops enriching and
scores leads blind while outreach looks healthy. Unipile does the polling
for this event on their side at randomised intervals, so it costs us nothing
against LinkedIn. Documented latency is up to 8 hours.

Always 200, even when nothing matched. Most relation events are the seat's
own organic networking, and a non-2xx makes Unipile retry a delivery that
was correctly a no-op.

Idempotent by construction: ``record_acceptance`` is write-once, so a
re-delivered event cannot walk the timestamp forward.

## Headers

- `x-unipile-signature` string, nullable

## Response `200`

Successful Response

- object

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/nudgelink/apis/nudgelink-api.md) · [All operations](https://skmtc.dev/nudgelink/apis/nudgelink-api/llms.txt) · [OpenAPI document](https://skmtc.dev/nudgelink/apis/nudgelink-api/revisions/baa46e6db986?raw)