`/v1/events`

Project auth (?project= required). See Concepts → Authentication.

`POST /v1/events`

What it does: Records a clicked or dismissed event against a broadcast. If the project has webhooks configured, fires a delivery to the customer's webhook URL.

When to use it: Never directly. The pre-built service worker at litepush.dev/litepush-sw.js beacons this on notificationclick and notificationclose. The endpoint silently drops requests that don't come with the right ?project= and a broadcast belonging to that project — manual calls without those will succeed-looking but no event is recorded.

Authentication: Project — ?project= is required. The broadcast referenced in the body must also belong to that project.

Request body:

Field	Type	Required	Description
`type`	`'clicked' \| 'dismissed'`	yes	Event type.
`broadcast_id`	string	yes	The `bdc_*` ID the notification came from. The service worker reads this from `event.notification.data.bid`.
`subscriber_id`	string	no	The `sub_*` ID of the receiver, if your SW knows it.

Example (illustrative — your SW handles this):

curl -X POST 'https://api.litepush.dev/v1/events?project=prj_xxxxxxxx' \
  -H "Content-Type: application/json" \
  -d '{ "type": "clicked", "broadcast_id": "bdc_01HXM..." }'

Success — 202 Accepted:

{ "ok": true }

Always returns 202 (even on silent drops) so it never noises up service-worker logs.

Attribution caveat. The service worker only knows the broadcast, not which subscriber it's running for — so clicked / dismissed events carry subscriber_id: null and external_id: null downstream. Correlate them by broadcast_id. Only delivered / failed (emitted server-side during fan-out) carry the full subscriber identity. See Webhooks.