API behaviour, time zones, rate limits and differences from the portal

The application programming interface returns coordinated universal time; the portal shows local time. That is the two hour offset most integrators notice first, and neither source is wrong. Rate limits apply per point, and deactivated or multi-product points are the usual reason for unexpected throttling.

Time zones

The interface returns coordinated universal time. South African local time is two hours ahead. The Augos API information document describes how to request local time when fetching data; the relevant section is early in the document and worth reading before you build any timestamp handling.

Rate limits

Two limits apply:

• 228 calls per point per day. The daily window starts at your first call, not at midnight.
• One call per point every five minutes.

Unexpected throttling

If you are getting rate-limit responses inconsistently, before assuming a platform fault:

1. Are you polling deactivated points? The authoritative list is the measurement points list endpoint. Anything not returned by it is disabled. Stale point lists are the most common cause here.

2. Are any of your points multi-product? A point carrying more than one product consumes one call per product type, so a single "point" in your list can burn several calls per cycle.

3. Is the point actually publishing that product? Some parameters are no longer pushed to the main platform. A point can exist and still not serve what you are asking for.

Refresh your point list from the endpoint, drop what is not returned, and count calls per product rather than per point. That resolves most of these.

Portal and interface disagreeing

They read the same store, so they will agree. If an interface fetch disagrees with an older export of the same period, the store changed between the two, which is normal: meters back-fill from buffer, spikes get removed, points get recalculated. See How current is my data.

If both the interface and a fresh portal download show the same gap, that is a real gap. Historical gaps that predate the background gap-filling service were never back-filled and need a manual run. Ask support, giving the point and the exact timestamps.

Still stuck

Email support@augos.io with the username, the endpoint you are calling, the point identifiers, exact timestamps and the response you are getting.