Get dedicated IP status

GET/api/v1/dedicated-ip
Requires anorganization API keywith the scopeaccount:read

Your dedicated sending address and its warm-up state. An organization on a shared IP gets a populated object whose state is shared and whose address is null — NOT a null result, and never an error. Reachable with an organization API key carrying account:read; a key without that scope is refused with 403.

Request

GET/api/v1/dedicated-ip
curl -X GET 'https://app.mailyte.com/api/v1/dedicated-ip' \
  -H 'Authorization: Bearer mk_live_YOUR_API_KEY'
The key names its own organization, so no X-Organization-ID header is needed.

Response

Success.

  • dataobject
    • objectstringdedicated_ip
    • statestringshared | requested | provisioning | warming | live | paused | quarantined

      The one lifecycle answer. `shared` is the default and where an organization that has never asked sits — it is an empty state, not an error. `requested` applied for, awaiting review; `provisioning` approved and being allocated; `warming` assigned and ramping (`warmup` is non-null); `live` fully warmed and sending at full rate; `paused` sending suspended but the address retained; `quarantined` withdrawn over a reputation problem. EVERY organization has one of these seven — an organization that has never asked is `shared`, not null — so **null means UNKNOWN: the state was not supplied**, and nothing else in this object can be read against it. In particular it never means "no dedicated IP"; that is `shared`.

    • addressstring

      The IP address allocated to this organization, once one exists. **null means NONE — no address has been allocated**, which is the case on the shared pool and while a request is still an application with nothing behind it. It is not a value we failed to read: the address is mirrored onto the organization here, so it is as readable as any other column.

    • spf_includestring

      What to add to your own SPF record to authorize this address, e.g. `include:spf.your-slug.example`. Minted for your organization and meaningless outside your DNS — it names no mail server of ours. **null means NONE — there is no address to authorize yet**, and it is derived from `address` rather than stored, so it is null exactly when that is. Naming a host before it exists would invite you to publish a reference to nothing.

    • requested_atstring

      When a dedicated IP was applied for. **null means NONE — no application has ever been made**, which is where an organization on the shared pool sits.

    • live_atstring

      When the address finished warming and began sending at full rate. **null means NONE — it has not gone live**, whether because it is still warming, still being provisioned, or was never requested. Read `state` for which. It is never a date we could not read.

    • warmupobject

      The ramp, while it is running. **THIS IS THE ONE FIELD IN THIS RESPONSE WHOSE NULL CARRIES TWO MEANINGS, and we cannot tell you which from this field alone.** Usually it is NONE: an address that is `live` has no warm-up left, and one not yet allocated has no ramp to describe. But it is also null when the warm-up ceiling could not be read, which is UNKNOWN. Resolve it with `state`: a null `warmup` while `state` is `warming` means the figures were unavailable — retry — and a null in any other state means there is genuinely no ramp. The service returns one null for both cases; fixing that means changing what it returns, so it is documented here rather than papered over.

      • dayinteger

        Which day of the warm-up schedule this is. Always populated inside a non-null `warmup`. **null means UNKNOWN — the figure was not supplied**, never day zero.

      • daily_limitinteger

        RECIPIENTS this address may take today. A limit, named like every other limit in the API — but NOT one whose null means "no limit": a warm-up always has a ceiling, and when that ceiling cannot be read the WHOLE `warmup` object is null rather than this field. So inside a non-null `warmup` this is always populated, and **null means UNKNOWN — the ceiling was not supplied.** Reading it as "uncapped" would let a client send at full rate through a ramp, which is the one thing a warm-up exists to prevent.

      • sent_todayinteger

        Recipients this address has taken today, counted from our own send history. Nothing sent reads `0`. **null means UNKNOWN — the count was not supplied**, never zero.

      • remaininginteger

        `daily_limit` minus `sent_today`, floored at zero. **null means UNKNOWN**, in exactly the cases the two figures it is derived from are — a derived number is as unknown as what it came from. A ramp with nothing left reads `0`.

      • completes_onstring

        When the ramp is scheduled to finish, on the current schedule. Projected from the date the warm-up started, so **null means UNKNOWN — that start date was missing or unreadable, and the finish could not be projected.** This one is genuinely reachable. It never means the ramp does not finish: you only see this object while `state` is `warming`, and a ramp that has finished has no `warmup` at all.

    • termsobject

      The dedicated-IP addendum, as it stands for this organization.

      • version_in_forcestring

        The addendum version a new request must accept today. A configured value on our side, the same for every organization, so it is always populated. **null means UNKNOWN — the version was not supplied**; it never means no addendum applies, and an empty string should be read the same way.

      • accepted_versionstring

        What this organization actually accepted. Stored verbatim, so it still says which text they read after a deploy has moved `version_in_force` on. **null means NONE — nothing has been accepted.** Compare it against `version_in_force`: they differ legitimately, and a difference is not an error.

      • accepted_atstring

        When the addendum was accepted. **null means NONE — nothing has been accepted**, and it is null exactly when `accepted_version` is: the two come from the same acceptance record, so they cannot disagree.

    • eligibilityobject

      Whether a dedicated IP can be requested, and the figures worth seeing before deciding to.

      • can_requestboolean

        Whether a request would be accepted right now. Governed by `requirements` alone; everything else in this object is disclosure and never blocks a request.

      • requirementsobject

        The two HARD requirements. Both must be true for `can_request`.

        • domain_verifiedboolean

          At least one domain verified for sending. See `verified_domains` for which.

        • marketing_approvedboolean
      • verified_domainsarray<string>

        Domain NAMES, not ids — the list that satisfies `domain_verified`, readable without a second lookup.

      • monthly_volumeinteger

        Emails actually sent over the last 30 days. A genuine `0` when nothing was sent: this is a local sum over our own event aggregates, and an organization that has sent nothing really has sent nothing. **null means UNKNOWN — the sum was not supplied**, and it is the one reading you must not treat as zero. Contrast `bounce_rate` beside it, where null is the honest answer to having sent nothing.

      • volume_thresholdinteger

        The volume at which a dedicated IP starts to pay for itself. Published beside `monthly_volume` in the same unit, with the comparison left to you rather than restated as a second field that could disagree. A configured figure on our side, identical for every organization, so **null means UNKNOWN — it was not supplied**, never "no threshold".

      • bounce_ratenumber

        Percentage of the last 30 days' deliveries that bounced, measured from your own send history. **null means NONE — there is nothing to rate, because nothing was sent in the window. Never 0.** A rate computed from no deliveries is not a good rate, and buying a dedicated IP on the strength of one would be acting on a number nobody measured. NOTE THIS IS NOT A REPUTATION SCORE and must not be read as one: it is a single measured ratio over a fixed window, with no judgement attached and none implied when it is null.

    • can_return_to_sharedboolean

      Whether this organization may move back to the shared pool, which the addendum permits at any time. It is also how an application is withdrawn.

Returned inside the standard envelope.

Errors

StatusWhen
401The API key is missing, unknown, revoked or expired. All four answer identically, on purpose: distinguishing them would confirm which keys exist.
403The key is valid but may not do this: it lacks the required scope, its IP allowlist does not include you, or this endpoint does not accept API keys.
404No such resource in this organization.
422The request was understood but the values were not acceptable.
429Too many requests, or the organization has spent its sending allowance. `Retry-After` says how long to wait.

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