BluNotify Partner API — Reference

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Every permission, granted or not. A 403 names a missing one by these keys (required_permission).

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The product the device was provisioned as: 'blunotify' (notification light) or 'bluem' (energy monitor). Null only for a device of a product this server does not know.

The channels the partner may command. Only on devices of a product that has named channels (BluNotify); absent on a BluEM meter.

BluNotify devices only: whether temperature automation drives the light (PUT .../automation).

With the health-read permission only.

With the health-read permission only.

With the health-read permission only.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The product the device was provisioned as: 'blunotify' (notification light) or 'bluem' (energy monitor). Null only for a device of a product this server does not know.

The channels the partner may command. Only on devices of a product that has named channels (BluNotify); absent on a BluEM meter.

BluNotify devices only: whether temperature automation drives the light (PUT .../automation).

With the health-read permission only.

With the health-read permission only.

With the health-read permission only.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

true on a response replayed for a repeated Idempotency-Key.

The resource created, or the one to poll for an outcome.

The 16-character root secret; only when the server generated it.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

When status last changed.

When the device last sent anything itself.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The half-open window [start, end) the answer covers.

Stream id, 8 hex characters.

When the interval began; null when the meter could not know (time_quality unknown).

Voltage, in volts (V), as measured.

Current, in amperes (A): the real load, already divided by ct_turns.

Real (active) power, in watts (W): the real load, already divided by ct_turns.

Mains frequency, in hertz (Hz), as measured.

Power factor, without unit (0 to 1), as measured.

The meter's lifetime energy counter, in watt-hours (Wh), at the record's first and last good read, divided by ct_turns (so fractional when ct_turns > 1).

CT turns the record was measured under (firmware emCtTurns; 1 when the record omitted it). a, w and energy_wh are already divided by it. null on a quarantined record whose ct was unusable.

When the server took the record off the network. Much later than start for a record the meter stored through an outage.

URL-safe. By start time: null on the last page. By arrival: never null; the bookmark to keep.

Arrival feed only.

Arrival feed only: the instant applied, or null on a cursor call.

Both modes. By start time: true exactly when next_cursor is set. By arrival: call again at once with next_cursor.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The half-open window [start, end) the answer covers.

Records with a start in the window.

Of those, quarantined.

Summed duration_s of the ones not quarantined.

Voltage, in volts (V), as measured.

Duration-weighted: sum(avg x duration_s) / sum(duration_s).

The lowest record min.

The highest record max.

Records that carry the quantity.

Their summed duration_s.

Current, in amperes (A): the real load, already divided by ct_turns.

Duration-weighted: sum(avg x duration_s) / sum(duration_s).

The lowest record min.

The highest record max.

Records that carry the quantity.

Their summed duration_s.

Real (active) power, in watts (W): the real load, already divided by ct_turns.

Duration-weighted: sum(avg x duration_s) / sum(duration_s).

The lowest record min.

The highest record max.

Records that carry the quantity.

Their summed duration_s.

Mains frequency, in hertz (Hz), as measured.

Duration-weighted: sum(avg x duration_s) / sum(duration_s).

The lowest record min.

The highest record max.

Records that carry the quantity.

Their summed duration_s.

Power factor, without unit (0 to 1), as measured. Over the records with a load only: those whose highest power before CT correction (power_w.max x ct_turns) reached 5 W. With nothing drawing, the meter reports a placeholder, not a ratio. A duration-weighted average of the records' own averages, not an energy-weighted power factor.

Duration-weighted: sum(avg x duration_s) / sum(duration_s).

The lowest record min.

The highest record max.

Records that carry the quantity.

Their summed duration_s.

Null when no record carried a counter reading.

Consumption over the window, in watt-hours (Wh): the total GET .../energy gives for the same window.

Energy-counter resets seen in the window.

Records the consumption is summed over.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The half-open window [start, end) the answer covers.

The bucket's first instant (with tz, in that zone).

Consumption in the bucket, in watt-hours (Wh).

The counter was reset in this bucket.

Consumption over the window, in watt-hours (Wh).

Energy-counter resets seen in the window.

Records the consumption is summed over.

Buckets with a reading.

Echoed when sent.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

true on a response replayed for a repeated Idempotency-Key.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The resource created, or the one to poll for an outcome.

true on a response replayed for a repeated Idempotency-Key.

After this the outcome is final.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Set when state is failed: busy, config_mode, unsupported, rejected or no_snapshot.

Set when state is done.

The unit's link to its meter at its last read.

True only when link is ok.

Voltage, in volts (V), as measured.

Current, in amperes (A): the real load, already divided by ct_turns.

Real (active) power, in watts (W): the real load, already divided by ct_turns.

Power factor, without unit (0 to 1), as measured. Null when nothing is drawing power.

Mains frequency, in hertz (Hz), as measured.

The CT turns the unit is set to.

Seconds between the meter reading these values and its answer.

When the answer reached the server.

Seconds from the request to the answer, to the millisecond (for example 1.278).

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The resource created, or the one to poll for an outcome.

true on a response replayed for a repeated Idempotency-Key.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The meter's answer, when final.

Why it failed, when it did.

When the meter answered, when final.

Pending only.

Pending only: the meter has logged a rejection that names no token since the request, which may or may not be this one's answer.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

true on a response replayed for a repeated Idempotency-Key.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

true on a response replayed for a repeated Idempotency-Key.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

true on a response replayed for a repeated Idempotency-Key.

The resource created, or the one to poll for an outcome.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

Bearer realm="BluNotify Partner API" (RFC 6750), with error="invalid_token" when a key was sent.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.

Seconds to wait before retrying.

The id of this request, on every response. Error bodies carry the same value as request_id; quote it to BluNotify support to find the call.

The per-partner request limit: requests per minute.

Requests the current minute still admits.

Seconds until the oldest request counted in the current minute leaves it, i.e. until RateLimit-Remaining next grows.

Always no-store on /v1: answers are one partner's, and some carry secrets.

The same value as the X-Request-Id header.

On a 403 refused because the key lacks a permission the request needs: its name, as GET /v1/account lists it (for example energy_read). Permissions are checked first, so with it granted the request can still be refused for something else. Absent on a 403 no permission would lift, and never on a 404.