> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nylon.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Webhook events

> The six events Nylon sends, and which ones your integration actually needs.

Nylon sends six events. Three are about a post finishing, three are about a connected account changing.

## Post events

| Event                      | When it fires                                   |
| -------------------------- | ----------------------------------------------- |
| `post.published`           | Every target on a post published.               |
| `post.partially_published` | Some targets published and at least one failed. |
| `post.failed`              | No target published.                            |

The three are mutually exclusive — exactly one fires per post.

`post.partially_published` is the one that catches people out. A post going to four accounts is four independent attempts, and three succeeding while one fails is a normal outcome, not an edge case. If you retry the whole post on this event you will publish twice on the three that worked.

<Note>
  You do not need these for posts you publish yourself and wait on — the API response already told you. They matter for **scheduled** posts, where nothing of yours is waiting.
</Note>

## Account events

| Event                     | When it fires                                              |
| ------------------------- | ---------------------------------------------------------- |
| `profile.connected`       | An account was connected, or reconnected.                  |
| `profile.disconnected`    | An account was disconnected and its credentials destroyed. |
| `profile.needs_attention` | An account's credentials stopped working.                  |

`profile.needs_attention` is the one worth wiring up first. It is how you tell a user their account needs reconnecting *before* their next scheduled post fails, rather than after.

`profile.connected` fires on a reconnection too, so it doubles as the "they fixed it" signal — use it to clear whatever warning you showed.

## Choosing a subset

An endpoint with every event ticked is stored as "no filter", which means it also receives event types Nylon adds later. An endpoint with a named subset receives exactly that subset and nothing new.

Pick deliberately:

* **Leave everything ticked** if your receiver ignores events it does not recognise. You get new capabilities for free.
* **Choose a subset** if an unknown event type would break your handler.

Both are fine; the failure mode is choosing "all" and then writing a handler that throws on anything unexpected.

## Filtering the delivery log by event

Open an endpoint from the Webhooks list and the delivery log underneath filters by event and by status — useful for answering "did any `profile.needs_attention` go out this week" without searching your own logs.

## Related

<Columns cols={2}>
  <Card title="Payload shapes" icon="square-terminal" href="/webhooks">
    What each event carries, and the envelope around it.
  </Card>

  <Card title="Deliveries and failures" icon="repeat" href="/help/webhook-deliveries-and-failures">
    What happens when your endpoint does not answer.
  </Card>
</Columns>