Understanding iMonnit API Rate Limiting and Serial Policy

The iMonnit REST API allows users to integrate their wireless sensor data securely into third-party applications using the programming language of their choice. Responses can be served in either XML (Extensible Markup Language) or JSON (JavaScript Object Notation).

To ensure system stability and fair resource distribution, Monnit enforces a structural policy on how requests are processed, alongside clear definition of resource overuse.

The Core Rule: Serial API Policy (Per Key)

iMonnit operates on a Serial API Policy. This means that all users are strictly limited to running API calls serially—one at a time, per API Key.

When designing your applications and scripts, your processes must wait for a response from the current API call before initiating the next one.

Monnit Knowledge Base

Critical Concurrency Warning: If your system attempts to execute overlapping or parallel calls using the same API Key, the system will reject the concurrent traffic and return an "API call rate exceeded" error.

If you have multiple independent applications or environments accessing the iMonnit API, ensure they are either strictly queued to run sequentially or utilize separate API Keys to avoid tripping this threshold.

Defining API Overuse

Monnit monitors request frequencies to protect core infrastructure. Excessive or redundant requests can result in the temporary or permanent revocation of your API portal access.

An primary example of overuse is making the same data request more frequently than the underlying data actually updates.

Monnit Knowledge Base

  • DataMessage Methods Limit: Standard data message endpoints are limited to a maximum frequency of 1 request per 10 minutes per key.

If your workflow requires real-time information, do not poll the REST API. Instead, utilize the iMonnit Webhook feature, which automatically pushes data to your server the moment a sensor checks in.

Authorization & Request Requirements

To successfully authenticate against the iMonnit API and maintain your connection state, your HTTP requests must conform to the following specifications:

Headers

Every posted request must include your secure authentication credentials embedded directly within the HTTP headers. You must pass both variables exactly as defined:

Monnit Knowledge Base

  • APIKeyID   
  • APISecretKey   

Note: You can generate and retrieve these credentials by logging into the iMonnit Online Portal, navigating to API, and selecting API Keys.

Parameters

API variables must be passed in the request as Param entries (query parameters or URL parameters depending on your client build). The parameter name is mapped as the Key, and your specific filtering criteria is mapped as the Value.

Time Zones

  • All dates and timestamps are handled strictly in UTC (Universal Coordinated Time). This applies universally to both the parameters you input and the timestamps returned in the XML/JSON output.

Best Practices for Compliance

  • Queue Your Requests: Implement a synchronous queue system in your code. Ensure your API client handles promises or callbacks linearly so that Request B never fires until Request A finishes processing.
  • Transition to Webhooks: If you find your application trying to scrape sensor data continuously, migrate your architecture to use Monnit Webhooks to eliminate incoming polling traffic entirely.
Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.