Command Line Ruby Python PHP Perl Java NodeJS Javascript


Welcome to the EKM METERING API!

We at EKM see easy access to your data, and the scalable systems behind the EKM Push, as crucial to moving our products into the future. To that end, we do what is unheard of in our industry, we give you your data for FREE.

The EKM API is organized around Representational State Transfer, or REST. You can use our Application Programming Interface, or API, to access EKM API endpoints, which can get you information on various EKM Push meter/ioStack data and utilize it in your own application, database, billing system, or building automation system.

We have language bindings in Shell (cURL), Ruby, Python, PHP, Perl, Java, Javascript and Nodejs! You can view code examples in the dark area to the right, and you can switch the programming language of the examples with the tabs in the top right.

Our API is designed to have predictable, resource-oriented URLs and to use HTTP response codes to indicate API errors. We use built-in HTTP features, like HTTP authentication and HTTP verbs, which can be understood by off-the-shelf HTTP clients, and we support cross-origin resource sharing to allow you to interact securely with our API from a client-side web application (though you should remember that you should never expose your secret EKM Push API key in any public website’s client-side code). JSON will be returned in all responses from the API, including errors (though if you’re using API bindings, we will convert the response to the appropriate language-specific object).


To authorize, make sure to use your personal EKM Push account key.

The examples in this API documentation use the demo key of MTAxMDoyMDIw. Please make sure you remove this key and place your personal key in the https address if you are trying to access the meters in your account.

With shell, you can just pass the correct address with each request
curl -s "URL Here"
Authorization: "EKM Push Key"
# Ruby Version: 3.1.2

# Load required modules
require 'net/http'
require 'json'
require 'uri'

# Call the call_api method to create a usable
# object named api_object from the API request URI
# Put the API request URI in the call

def call_api(api_path)
  uri = URI.parse("URL Here#{api_path}")
  response = Net::HTTP.get_response(uri)
  puts response.uri

# Call the call_api method to create a usable
# object named api_object from the API request URI
# Put the API request URI in the call
# URI only NOT URL - Do not include for example
api_object = call_api('URI Here')

# This just displays the object but you can use what ever
# code you would like to work with the object here
require 'pp'
pp api_object

Python version: 3.9.12

# Required Python Modules
import urllib.request
import urllib.error
import urllib.parse
import json
import pprint

# This function accesses the api_request URL and converts
# the contents to a usable Python object and returns it
def call_api ( api_request ):
    Make http request
    response = urllib.request.urlopen(api_request)
    response =
    json_object = json.loads(response.decode())
    return json_object

# Call the call_api function to create a usable
# object named api_object from the API request URL.
# Put the API request URL in the call
api_object = call_api("URL Here")

# This just displays the object but you can use what ever
# code you would like to work with the object here

// PHP 8.0.17 (cli)

// Call the callApi function to create a usable
// object named $apiObject from the API request URL.
// Put the API request URL in the call
$apiObject=callApi('URL Here');

// This just displays the object but you can use what ever
// code you would like to work with the object here

// This function accesses the apiRequest URL and converts
// the contents to a usable PHP object and returns it
function callApi ($apiRequest='') {

        return ($jsonObject);

# Perl version: v5.34
# version 2.2
# Perl Modules Version:
# JSON: 4.05
# LWP::Protocol::https: 6.10
# LWP::Simple: 6.62
# OS Prerequisites
# apt install cpanminus
# Install Perl Modules
#       cpan LWP::Simple
#       cpan LWP::Protocol::https
#       cpan JSON

# Required Perl Modules
use strict;
use warnings;
use LWP::Simple;
use JSON;
use Data::Dumper;

# This function accesses the api_request URL and converts
# the contents to a usable Perl object and returns it
sub call_api {
    my $api_request = shift;
    my $json_text   = get($api_request);
    my $json_object = JSON->new->utf8->decode($json_text);
    return $json_object;

# Call the call_api function to create a usable
# object named api_object from the API request URL.
# Put the API request URL in the call
my $api_object = call_api('URL Here');

# This just displays the object but you can use what ever
# code you would like to work with the object here
print Dumper($api_object);    ## no critic (InputOutput::RequireCheckedSyscalls)

 openjdk version "17.0.2" 2022-01-18

 Download the correct org.json jar version for your
 needs from:

 This example uses version 20220320 accessible here:

 Instructions to run this program

 1. Put this code in a file named
 2. Copy the downloaded org.json jar and to the same directory
 3. Compile
  javac -cp .:./json-20220320.jar ./
 4. Run
  java -cp .:./json-20220320.jar EKM

//Import required classes
import org.json.*;

@java.lang.SuppressWarnings({"java:S106", "java:S112", "java:S125"})

public class EKM {
    public static JSONObject callApi(String apiRequest) throws Exception {

        // This code accesses the apiRequest URL and converts
        // the contents to a usable JSON object

        URL url = new URL(apiRequest);
        URLConnection connection = url.openConnection();
        BufferedReader in = new BufferedReader(
                                               new InputStreamReader(

        StringBuilder response = new StringBuilder();
        String inputLine;

        while ((inputLine = in.readLine()) != null)


        return new JSONObject(response.toString());

    public static void main(String[] args) throws Exception {
         Call callApi to create a usable
         object named apiObject from the API request URL.
         Put the API request URL in the call
        JSONObject apiObject = EKM.callApi("URL Here");

         You can access any part of the apiObject using code like this:
         JSONArray  readData = apiObject.getJSONObject("readmeter").getJSONArray("ReadSet").

        // This just outputs the whole apiObject
<!DOCTYPE html>
<script type="text/javascript">

// The example function is called from the 
// body tag when the page loads
function example(){

// Call the callApi function to create a usable
// object named apiObject from the API request URL.
// Put the API request URL in the call
callApi('URL Here',function(apiObject){

       // This just displays the object in the result div
       // you can use what ever code you would like to work 
       // with the object here
       document.getElementById("result").innerHTML = "<pre>"+JSON.stringify(apiObject, null, 4)+"</pre>";


// This code accesses the apiRequest URL and converts
// the contents to a usable JSON object named apiObject
function callApi(apiRequest,callback) {
    var xhttp = new XMLHttpRequest();
    xhttp.onreadystatechange = function() {
      if (xhttp.readyState == 4 && xhttp.status == 200) {
        var jsonObject = JSON.parse(xhttp.responseText);
    };"GET", apiRequest, true);

  <body onload="example()">
    <div id="result"/>
* Requirements
* NodeJS: v16.14.2
* Axios:  0.27.2

// Load modules
const axios = require('axios');

const apiClient = axios.create({
  baseURL: 'URL Here',
  timeout: 1000 * 15,

// This code accesses the apiRequest query and
// logs the response data or the error
;(async () => {
  try {
    const res = await apiClient.get('URI Here');
    const apiResData =;

    console.log(JSON.stringify(apiResData, null, 2));
  } catch (error) {

Make sure to replace the sample key: MTAxMDoyMDIw, with your API key in the https address.

EKM uses API keys to allow access to the API. You authenticate to the EKM API by providing one of your unique API keys in each request. Each Push account holder is provided with an EKM Push User Key, which provides access to all meters in their account. This key carries lots of privileges so we encourage you to keep it secret. In addition to this master key, additional keys are also provided to give access to each meter/ioStack individually, and keys can be created to provide access to sub groups of meters/ioStacks upon request. These secondary keys can be used to share single meters/ioStacks, or a subset of meters/ioStacks, without sharing access to all meters/ioStacks in an account. For example, if you are a landlord with multiple rentals and meters/ioStacks, you could share specific meter/ioStack keys with each of your tenants, so that they could have access to only the data that pertains to their usage.

Authentication to the API occurs via HTTP Basic Auth. Provide your API key as the basic authorized username. You do not need to provide a password. You must authenticate for all requests.

The EKM Push API expects the API key to be included in all requests to the server. The key is included in the URL in the following way:

Authorization: key=MTAxMDoyMDIw

Realtime API

Click here to go to Realtime Documentation

If you are developing your own app, cloud-to-cloud solution, billing system, or other SAS solution, our Real-Time API allows you to easily access your EKM Push data in any format that you need. Below you will find descriptions regarding how to access the data, and about the filters you can apply so the data comes to you in a format that is easily digested and inserted into your software solution.

The real-time API provides the 1,000 latest meter readings for each of your meters/IOStack devices. If your device is being read once per minute, the data will be made available once per minute, per device. Whether you have one device or 10,000 devices, this is the easiest and most scalable way to access your data.

The EKM Dash, EKM Widget,,,, the other solutions in our Push App Store, as well as other customers that have their own custom solutions, all use this API to access their data. We use the same API as you and do not give ourselves any special permissions, we see what you see, which forces us to make the API as great as possible for everyone. We have even given you code examples that can be copy and pasted into your own software language to make the data access that much easier.

Use the API definition, metered values definition, code snippet suggestion, and guide to get you on your way to developing your next killer app. If you create something great, let us know; we’re open to adding all useful apps into the Push App Store.

We also have a Realtime API Request Builder Tool found here:

Realtime API Builder

Account API

Click here to go to Account API Documentation

This API provides information for accounts and devices owned by the account.

Get information for the specified target, which can be account, gateway, meter or ioStack.

You could make API request with the EKM Push Key that is your own Authorization Key that you received for your Push Account, or instead the EKM Push Key you could use Gateway Key for more restricted access. Be aware that if you use the Gateway Key, you will only receive information regards to that gateway.

Gateway Settings API

Click here to go to Gateway Settings API Documentation

This API is used to send commands and settings to devices connected to a Push3 gateway as well as the gateway device itself.

Trigger API

Click here to go to Trigger API Documentation

A REST API to lookup/create/update/delete triggers.

EKM Push3 gateway triggers are one of the most powerful tools that EKM has to offer. You can automate how and when the EKM Push system will react to metered values. You can have the Push gateway send you an email or control a relay to turn on/off a switch or close a valve based on the metered data for example. Push3 gateways have the ability trigger specific actions based on conditions that you set up. Triggers live on the Push3 gateways so they will continue to function even without an internet connection. Triggers can control the relays on the v.4 Omnimeters, in order to turn something on or off, or they can email you notifications of the trigger. Please note: v.3 Omnimeters do not have controllable relays, so the relay triggers will not work, but the email triggers will.

Summary API

Click here to go to Summary Documentation

Our Summary API takes every Real-Time read, over 15 minute time periods, and summarizes them into single 15 minute summaries. We store this data forever to provide a long term historical dataset for each meter. Our system can then combine these summaries together to summarize hours, days, weeks, and months. This dataset is often the best way to get historical values like kWh, pulse counts, etc. It also provides averages, min. and max. values, difference, and more. We make this data available to you via our Summary API in a very similar way to our Real-Time API.

You can use the Summary API definition to access the data you need, from 15 minutes to years of data. We have gone to great lengths to provide this data for free in order to add value to our metering systems. The Summary API, the Real-Time API, great affordable hardware, and scalable access to your data are all components of the most powerful, and highest value metering system available in the world.

We also have a Summary API Request Builder Tool found here: Summary API Builder

Summary V2 API

Click here to go to Summary V2 Documentation

Summary V2 API is a new set of summary features, such as First/Last to get the first and/or last reported date for the given meter(s)/ioStack(s), GStat for getting the status of one or more gateways, IOStack for getting information from new sensors, and more.

The API V2 summary and documentation are currently in beta, signifying that they are subject to changes and updates. It’s important to note that the API V2 calls and specifications provided in this documentation may undergo modifications as the beta phase progresses. Users should stay informed and regularly check for updates to ensure compatibility and adherence to the latest specifications

RS-485 Communications

Click here to go to RS-485 Documentation

This section is for developers, or individuals, that want to communicate with their EKM Meters directly using their own software or embedded solution.

The code examples found in this section are in the simplest possible method to get you started. You are welcome to make them more robust.

First we start you out just connecting to the meter. You will find there is a very simple command line process to help you get started.

After that we cover the CRC method required for most communication to the meter.

Then we put it all together, in a simple test script that will show reads, and also open and close the relays.

Last we cover how to convert the 255 character strings that the meter responds with to a usable array containing field names and their values. It is our hope that after you go through these steps you will have all the information you need, to build whatever tools you like to access the meter.

Our meters use an IEC 62056-21 communication standard that has been optimized for our own needs. We are more than happy to share this with you. With this you can write your own software or embedded solution to access your meter data.

IEC 62056 is a set of standards for Electricity metering data exchange by International Electrotechnical Commission.

To learn more about the IEC 62056 standard click the button below to visit the WikiPedia website.

Additional PDF docs are available:

v.3 Meter Settings Protocol

v.3 Meter Parsing

v.4/v.5 Meter Settings Protocol

v.4/v.5 Meter Parsing

v.4/v.5 Meter Alternate Modbus Protocol

If you are coding in Python you can also make use of our API.

Status Codes

EKM uses conventional HTTP response codes in addition to our API Status Codes to indicate the success or failure of an API request. In general, codes in the 2xx range indicate success, codes in the 4xx range indicate an error that failed given the information provided, and codes in the 5xx range indicate an error with EKM’s servers (these are rare).

The EKM API uses the following API specific Status codes:

API Status Code Meaning
1000 There is not data for: {meters}
1001 There is not data for: {meters} between ${startDate} and ${endDate}
1002 There is not data for: {meters} This meter first reported on:
1003 There is not data for: {meters} This meter last reported on:
1004 Timezone is not supported for this date range request
1100 All invalid query requests
1101 Invalid format
1102 Invalid value
1103 Invalid parameter
1200 Found invalid meter: {meter} for key: MTAxMDoyMDIw
1300 Oops! It looks like there was an unexpected error. Try checking your query for issues or hold tight while we see what we can do. This error has been reported.

The EKM API also uses the following HTTP Status codes:

HTTP Status Code Meaning
200 OK – The request succeeded.
400 Bad Request – The server could not understand the request due to invalid syntax.
401 Unauthorized – Although the HTTP standard specifies “unauthorized”, semantically this response means “unauthenticated”. That is, the client must authenticate itself to get the requested response.
403 Forbidden – The client does not have access rights to the content; that is, it is unauthorized, so the server is refusing to give the requested resource. Unlike 401 Unauthorized, the client’s identity is known to the server.
404 Not Found – The server can not find the requested resource. In the browser, this means the URL is not recognized. In an API, this can also mean that the endpoint is valid but the resource itself does not exist. Servers may also send this response instead of 403 Forbidden to hide the existence of a resource from an unauthorized client. This response code is probably the most well known due to its frequent occurrence on the web.
429 Too Many Requests – The user has sent too many requests in a given amount of time (“rate limiting”).
500 Internal Server Error – The server has encountered a situation it does not know how to handle.
501 Not Implemented – The Vertical Bar otherwise known as “pipe” request method is not supported by the server and cannot be handled. The only methods that servers are required to support (and therefore that must not return this code) are GET and HEAD.
502 Bad Gateway – This error response means that the server, while working as a gateway to get a response needed to handle the request, got an invalid response.
503 Service Unavailable – The server is not ready to handle the request. Common causes are a server that is down for maintenance or that is overloaded. Note that together with this response, a user-friendly page explaining the problem should be sent. This response should be used for temporary conditions and the Retry-After HTTP header should, if possible, contain the estimated time before the recovery of the service. The webmaster must also take care about the caching-related headers that are sent along with this response, as these temporary condition responses should usually not be cached.
504 Gateway Timeout – This error response is given when the server is acting as a gateway and cannot get a response in time.
505 HTTP Version Not Supported – The HTTP version used in the request is not supported by the server.
506 Variant Also Negotiates – The server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.
510 Not Extended – Further extensions to the request are required for the server to fulfill it.
511 Network Authentication Required – Indicates that the client needs to authenticate to gain network access.

Widget Documentation

Click here to go to Widget Documentation

Access free web-based real-time and historical graphs showcasing your EKM Push data, covering all your devices including meters and ioStacks. It’s quick, easy, and doesn’t require a login.

The EKM Widget offers a convenient means to gain visual insights into your systems’ performance. We utilize it to monitor our office’s current consumption and solar power generation in real-time. Additionally, the historical chart helps us track the impact of efficiency upgrades on our usage and monitor the energy consumption of our electric car over time.