Leap provides access to programs that dispatch and measure performance at either the utility meter (e.g. residential home or commercial site) or the individual device (e.g. battery, EV charger, or thermostat). The “Leap meter” refers to the asset where dispatching and performance measurement occurs and where revenue is generated from. The Leap `meter_id` is the unique ID that is used to identify this asset.

Since a utility meter can have multiple controllable devices behind it (e.g. 2 thermostats and an EV charger), there are some differences in processing Leap meters that are utility meters compared to Leap meters that are individual devices. The `meter_type` parameter within the Meters API response enables partners to tell which type (`utility_meter` vs. `device`) each Leap meter is.

### Processing Utility Meters vs. Devices

The table and database options below outline approaches for handling the differences between utility meter and device type Leap meters.

|  | Partner Reference ID | Meters Processing | Dispatch Processing | Interval Data Upload |
| --- | --- | --- | --- | --- |
| _Integration guidance_ | - Define [partner_reference](https://developer.leap.energy/docs/partner-created-meters#global-required-fields) or [refId](https://developer.leap.energy/docs/leap-connect#connect-variables) as a unique identifier based on utility meter vs. device type_ | _Look for `meter_type` field in the Meters API response to determine how to store `meter_id`_ | _Lookup dispatched `meter_id` in relevant database table(s) to determine which device or group of devices to dispatch_ | _For [programs](https://developer.leap.energy/docs/onboard-overview) that require interval data upload_ |
| `utility_meter` | `partner_reference` or `refId` set to **customer/site ID** | If **`utility_meter`**, store according to guidance below | Dispatch **all associated devices** | If applicable, upload interval data for **each utility meter** using corresponding `meter_id` |
| `device` | `partner_reference` or `refId` set to **device ID**<br>(or if desired a combination of **customer/site ID + device ID**) | If **`device`**, store according to guidance below | Dispatch **that individual device** | Upload interval data for **each device** using corresponding `meter_id` |

### Where to Store Leap Meter IDs

Depending on the meter type, you will need to adjust how you [Sync Meter Inventory](https://developer.leap.energy/docs/sync-meter-updates) and store the associated Leap meter ID in your internal database. How you store this is ultimately up to you and dependent on your database architecture, but provided below are some possible options with `meter_type` differences outlined:

**Option A: Store all meters in a dedicated meters table**

This approach stores all meters together with an additional field to indicate the meter type and would link back to customer/site and device tables accordingly. This would simplify the Meters API and Dispatch API integrations since all Leap meter IDs would be written to and looked up in the same table.

- If `utility_meter`, store as such so it can be associated with all controllable devices behind that meter
- If `device`, store as such so it can be associated to that individual device

**Option B: Store all meters in existing device table**

This approach is a variation of the above option but stores meters directly in your existing device table.

- If `utility_meter`, store in device table for all controllable devices behind that meter
- If `device`, store in device table for that individual device

Important notes:

- A customer could have a device in both a utility meter program and a device level program and therefore up to 2 Leap meter IDs must be able to be stored for each device. If you are unable to store 2 meter IDs in a single field, you would need to have 2 separate fields and your Dispatch API integration would have to look for meter IDs in both fields. For example:
  - If `utility_meter`, store in a “leap_utility_meter_id” field
  - If `device`, store in a “leap_device_meter_id” field
- If participating in a utility_meter level program, each new controllable device added over time would need to have the utility_meter `meter_id` assigned

**Option C: Store in customer & device table depending on meter type**

This approach allows for storing the Leap meter ID in the location that the meter ID is uniquely identifying based on the meter type and where event performance is being calculated. This requires that Meters API and Dispatch API integrations write to and lookup Leap meter IDs in both tables.

- If `utility_meter`, store in customer/site table
- If `device`, store in device table

### Note on Sub-Meters

It is possible to create partner-created meters with a meter_type of `submeter` instead of `utility_meter` or `device`. This would be used in the rare case that you have access to submeter data (instead of utility_meter or device level data) at a customer site. If this occurs, this `submeter` value would show up as a meter_type in the Meters API response as well. In that case, you would need to process these similar to a `utility_meter` where any controllable devices behind that submeter would be tied to the relevant Leap `meter_id`.