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

# Merging, splitting, and linking

As you work incidents, your understanding of an event changes. What looked like six separate charger problems may turn out to be one site-wide outage; a single incident may turn out to be two unrelated issues. Merge, split, and link let you reshape incidents to match reality.

## Merging

**Merging** consolidates several incidents into one **primary** incident. Use it when multiple incidents are really the same event — for example, every charger at a site going down together.

When you merge:

* The merged incidents move to the `MERGED` status and point at the primary.
* Their affected stations, comments, and fault detail move onto the primary, so the primary now shows the whole picture.
* **Merged incidents drop out of the default incident list.** They are still retrievable, and a request for one still returns it with a pointer to the primary so you can follow the redirect. To include them in a listing, ask for merged incidents explicitly (`includeMerged=true`).

Merging is bounded so it stays meaningful: every incident you merge in must be at the **same location** and of the **same type** (`alertType`) as the primary. A single merge call can fold in up to 50 incidents — enough for a full site in one step.

```
POST /incident-management/v1/incidents/{primaryId}/merge
```

## Splitting

**Splitting** is the inverse: it separates stations back out of a merged incident. Use it when a merge turns out to be too broad — one charger at the site had an unrelated problem, say.

When you split stations out, each station's **original incident is revived** — it comes back with its own history and detection time, rather than a brand-new incident being created. The stations leave the source incident's roster and rejoin their revived incident.

Only stations that arrived by merge can be split out. Each such roster row names its origin in `mergedFromIncidentId`; the stations that opened the incident carry no origin and cannot be split away from it, so a split request naming one of them is refused. Read the roster to see which rows qualify — see [Affected stations](/guides/incidents/affected-stations).

```
POST /incident-management/v1/incidents/{id}/split
```

## Linking

**Linking** is lighter than merging. It marks two incidents as **related** without combining them — each keeps its own status, roster, and lifecycle. Use it to connect incidents that inform each other but should be worked separately, for example a recurring fault and the earlier incident it resembles.

Linking is symmetric: the relationship shows on both incidents, and appears on both of their activity feeds. Unlinking removes it from both.

```
POST /incident-management/v1/incidents/link
POST /incident-management/v1/incidents/unlink
```

Some links are created for you: when the platform opens an incident that resembles a recently resolved one — on the same station, or elsewhere at the same location — it links the two automatically so the history is easy to find.

## Which one to use

| You want to…                                                          | Use   |
| --------------------------------------------------------------------- | ----- |
| Treat several incidents as one event, worked together                 | Merge |
| Undo a merge for specific stations                                    | Split |
| Note that two incidents are related, but keep working them separately | Link  |

See [API usage](/guides/incidents/api-usage) for the request bodies, and [Comments and history](/guides/incidents/comments-and-history) for how these actions appear on an incident's feed.