Skip to main content
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.

​
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.

​
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.
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

See API usage for the request bodies, and Comments and history for how these actions appear on an incident’s feed.