Limits a domain

Parameters

Request

curl -X GET 'https://app.mailyte.com/api/v1/domains/yourdomain.com/limits' \
  -H 'Authorization: Bearer mk_live_YOUR_API_KEY'

const response = await fetch('https://app.mailyte.com/api/v1/domains/yourdomain.com/limits', {
  method: 'GET',
  headers: {
    Authorization: 'Bearer mk_live_YOUR_API_KEY',
  },
});
const { data } = await response.json();

import requests
response = requests.get(
    "https://app.mailyte.com/api/v1/domains/yourdomain.com/limits",
    headers={"Authorization": "Bearer mk_live_YOUR_API_KEY"},
)
data = response.json()["data"]

<?php

$response = Http::withToken('mk_live_YOUR_API_KEY')
    ->get('https://app.mailyte.com/api/v1/domains/yourdomain.com/limits');

$data = $response->json('data');

require "net/http"
require "json"
uri = URI("https://app.mailyte.com/api/v1/domains/yourdomain.com/limits")
request = Net::HTTP::Get.new(uri)
request["Authorization"] = "Bearer mk_live_YOUR_API_KEY"
response = Net::HTTP.start(uri.hostname, uri.port, use_ssl: true) { |http| http.request(request) }

Response

Success.

• dataobject
  • objectstringlimits
  • subjectstringdomain | mailbox

    What these limits are about.

  • identifierstring

    The domain name, or the mailbox address.

  • sending_rateobject

    Outbound rate limits and what has been used against them. Null when the mail server could not be reached -- unknown, not zero.

    • limitsobject

      Messages permitted per window. **0 means no limit** for a window; null means the ceiling is unknown. See each field -- reading those two the wrong way round has opposite consequences.

      • hourlyinteger

        Messages permitted per hour. **0 means NO LIMIT** for this window -- it is the mail server's own convention, not an absence of data, and a client that reads 0 as "capped at nothing" blocks a customer who has no cap. Null is the opposite reading: UNKNOWN. The configuration is always complete when it is returned at all -- the rate limiter substitutes a default rule for an entity it has no row for -- so a null here means it answered without its configuration and no ceiling could be read. Null is never "no limit".

      • dailyinteger

        Messages permitted per day. **0 means NO LIMIT** for this window -- it is the mail server's own convention, not an absence of data, and a client that reads 0 as "capped at nothing" blocks a customer who has no cap. Null is the opposite reading: UNKNOWN. The configuration is always complete when it is returned at all -- the rate limiter substitutes a default rule for an entity it has no row for -- so a null here means it answered without its configuration and no ceiling could be read. Null is never "no limit".

      • monthlyinteger

        Messages permitted per calendar month. **0 means NO LIMIT** for this window -- it is the mail server's own convention, not an absence of data, and a client that reads 0 as "capped at nothing" blocks a customer who has no cap. Null is the opposite reading: UNKNOWN. The configuration is always complete when it is returned at all -- the rate limiter substitutes a default rule for an entity it has no row for -- so a null here means it answered without its configuration and no ceiling could be read. Null is never "no limit".

      • burstinteger

        Messages permitted per burst window. **0 means NO LIMIT** for this window -- it is the mail server's own convention, not an absence of data, and a client that reads 0 as "capped at nothing" blocks a customer who has no cap. Null is the opposite reading: UNKNOWN. The configuration is always complete when it is returned at all -- the rate limiter substitutes a default rule for an entity it has no row for -- so a null here means it answered without its configuration and no ceiling could be read. Null is never "no limit". Note that this ceiling is carried in the configuration but is NOT one of the windows the mail server actually enforces on a send, so it describes intent rather than what will stop a message.

    • usedobject

      Consumed so far in each window. Subtract from `limits` for what is left; there is deliberately no second field saying so. Null means the meter was not read, and 0 is weaker evidence than it looks -- see each field.

      • hourlyinteger

        Messages sent in the current hour. Null means UNKNOWN -- the meter was not read. **Treat 0 with the same caution**: when its counter store is unavailable the rate limiter substitutes zeroed counters of its own rather than failing, so 0 means "no usage was recorded", which is not the same as proof that nothing was sent. Do not bill, throttle or report quota exhaustion from this figure alone.

      • dailyinteger

        Messages sent in the current day. Null means UNKNOWN -- the meter was not read. **Treat 0 with the same caution**: when its counter store is unavailable the rate limiter substitutes zeroed counters of its own rather than failing, so 0 means "no usage was recorded", which is not the same as proof that nothing was sent. Do not bill, throttle or report quota exhaustion from this figure alone.

      • monthlyinteger

        Messages sent in the current calendar month. Null means UNKNOWN -- the meter was not read. **Treat 0 with the same caution**: when its counter store is unavailable the rate limiter substitutes zeroed counters of its own rather than failing, so 0 means "no usage was recorded", which is not the same as proof that nothing was sent. Do not bill, throttle or report quota exhaustion from this figure alone.

  • storageobject

    Stored mail. Usage and quota are two separate upstream calls, so one can be known while the other is not; this block is null only when BOTH were unreachable -- unknown, not zero.

    • used_bytesinteger

      Bytes currently stored. Null means UNKNOWN -- the usage call failed, or the mail server holds no usage row for this entity yet. 0 means it was measured and is empty. The quota fields beside this one come from a different call and are unaffected either way.

    • quota_bytesinteger

      Bytes permitted. **Null has two readings and `message_size` separates them.** When `message_size` is present the quota call succeeded and null means NO LIMIT -- storage is uncapped for this entity, with organization-level inheritance already applied upstream, so it is a settled answer and not "ask the parent". When `message_size` is also null the quota call itself failed and this is UNKNOWN. Note this is the OPPOSITE convention from `sending_rate.limits`, where no limit is 0; the two figures come from two different services.

    • messagesinteger

      Messages stored. Null means UNKNOWN, on exactly the same terms as `used_bytes` -- it is read by the same call. 0 means measured and empty.

  • message_sizeobject

    Per-message ceilings enforced at delivery. Null when the mail server could not be reached -- unknown, not zero. Because this block is present only when the quota call succeeded, it also tells you how to read `storage.quota_bytes`.

    • max_message_bytesinteger

      Bytes. Null means NO LIMIT -- no ceiling is configured for this entity or inherited from its organization. This block exists only when the quota call succeeded, so null here is never "unknown".

    • max_attachment_bytesinteger

      Bytes. Null means NO LIMIT, on the same terms as `max_message_bytes`: settled, not unknown.

Returned inside the standard envelope.

Errors

Every status, with what causes it and what to do, is on the error reference.