Dispatch events could come from a variety of sources depending on the program. For example, these could be triggered by a program operator due to grid stress or emergency, or simply as a test to validate performance. They could also be created by Leap as a way to validate performance for capacity payments. Or it could be a market award given as the result of clearing in a wholesale energy marketplace.

Regardless of the source, it is important to respond in a timely and consistent manner to ensure good performance and maximize revenue. The sections below provide guidance on how to process these incoming event notifications.

### Market & Program-Agnostic Integrations  
It is recommended to keep your dispatch integration and event processing generic across markets and programs to enable expansion to new programs and revenue streams without requiring any integration updates or code changes.

For this reason, the dispatch information and logic provided in this guide is intended to be applicable for all markets and programs. Where there are significant and relevant differences in behavior between markets/programs, those are noted accordingly.

**Example Market Group Event Notification**

```json
{
  "integration_test_notification": false,
  "communication_test": false,
  "group_dispatches": [
    {
      "market_group_id": "11aa7aae-24e5-455f-91e9-e0f5f145f2ae",
      "meter_ids": [
        "abae2779-e392-4f00-b0cf-32e716204f78",
        "bbae2779-e392-4f00-b0cf-32e716204f78"
      ],
      "timeslots": [
        {
          "market_group_event_id": "114751e8-c0df-4d69-8a4f-9e7cebef1f84",
          "start_time": "2023-06-04T23:00:00Z",
          "end_time": "2023-06-05T00:00:00Z",
          "cancelled": false,
          "performance_compensation_cap": "up-to-site-load",
          "priority": 2,
          "is_voluntary": false,
          "dispatch_event_types": [
            "day-ahead"
          ],
          "programs": [
            "CCA"
          ],
          "energy_kw": 8.500,
          "nomination_kw": 11.000
        }
      ]
    }
  ]
}
```

### Event Processing

### Key Event Fields  
To schedule events, most implementations only require parsing the following fields. With this information, you can schedule the curtailment or export of energy from customer devices at the appropriate time and for the expected length of time.

1. `market_group_event_id` (or `meter_event_id`) - To understand if this is for a new or existing event
2. `meter_ids` (or `market_group_id`) - To lookup which customer devices need to have their schedule updated
3. `start_time` & `end_time` - To understand the start time and duration of the event

### Overlapping Events & Event Consolidation  
It is possible to receive overlapping dispatches for certain timeslots if events are triggered for different reasons or for multiple stackable programs so ensure that your implementation can process and combine these overlapping time periods appropriately.

### Updates to Existing Events  
If an event notification comes in with an already received `meter_event_id` or `market_group_event_id`, see guidance below to see what, if anything, has changed for the event:

1. Cancelled Event - `cancelled` would be set to "true"
2. Modified Event - Modifications to events can happen occasionally and your integration needs to be able to handle and process these event updates. Any of the fields that changed from the original event notification should be updated.

### Event Power & Energy  
The `energy_kw` field provides the **power** in kW to be curtailed/exported for the duration of the event (if your technology can directly control this).

### Example Code Recipes  
The recipes below walk through example dispatch event processing code:

- Process dispatch events from meter-level webhook
- Process dispatch events after polling meter-level API

### Dispatch Strategies & Additional Event Fields  
Depending on your technology and customer experience requirements, you may choose to implement one or combine multiple of these strategies below.

### Strategy A: Maximize revenue by responding to all events  
When no event duration constraints exist, you can simply use the above mentioned key event fields to respond to all events to maximize revenue. This is the recommended approach whenever possible.

### Strategy B: Prioritize events when max event duration constraints exist  
Use the `priority` field to choose the most lucrative time periods when max event duration constraints exist.

### Strategy C: Increase revenue when controlling onsite batteries  
When controlling battery discharge rates, use the `performance_compensation_cap` to determine when discharging beyond the specified `energy_kw` will be compensated for:

### Strategy D: Gain flexibility when prioritizing along with outside factors  
When daily response flexibility is needed, energy curtailment can be reduced or events can be ignored when the `is_voluntary` field is set to true.