Skip to content
nsin nsin nsin Docs

Get outage-detection settings for one domain

GET
/reseller/v1/domains/{domainId}/uptime/settings
 
curl --request GET \
  --url https://api.nsin.cloud/reseller/v1/domains/1/uptime/settings \
  --header 'Authorization: Bearer <token>'

This domain’s detection thresholds, with the valid range for each in bounds.

The values are the CLAMPED ones — what the detector will actually use — not the raw column values. A window stored above the deployment’s cap is reported at the cap, so the panel never shows a setting that is not in force.

Authorizations

Section titled “Authorizations ”

Parameters

Section titled “ Parameters ”

Path Parameters

Section titled “Path Parameters ”
domainId
required
integer

Must belong to a client of the caller, or the response is 403.

Responses

Section titled “ Responses ”

200

Section titled “200 ”

Current settings

Media type application/json
object
enabled
required

Whether outage alerts are sent for this domain.

boolean
threshold_pct
required

Per-minute origin-error percentage that counts as down.

integer
window_min
required

Minutes the host must stay down before an incident opens.

integer
min_requests
required

Traffic floor — below this, no incident opens. It is what stops one failed request on a near-idle staging host paging somebody at 3am.

integer
min_active_min
required

Minimum populated one-minute buckets required in the window.

integer
recover_min
required

Consecutive clear minutes before an incident resolves.

integer
bounds
required

Valid range for each configurable field, served with the values so a form can bound its own inputs instead of hard-coding limits that a deployment can change under it.

object
threshold_pct_min
required
integer
threshold_pct_max
required
integer
window_min_min
required
integer
window_min_max
required

Deployment-wide cap; not a constant.

integer
min_requests_min
required
integer
recover_min_min
required
integer
recover_min_max
required
integer
Example generated
{
  "enabled": true,
  "threshold_pct": 1,
  "window_min": 1,
  "min_requests": 1,
  "min_active_min": 1,
  "recover_min": 1,
  "bounds": {
    "threshold_pct_min": 1,
    "threshold_pct_max": 1,
    "window_min_min": 1,
    "window_min_max": 1,
    "min_requests_min": 1,
    "recover_min_min": 1,
    "recover_min_max": 1
  }
}

401

Section titled “401 ”

Missing, malformed, expired, or revoked credential.

Media type application/json

Every error body carries error, a human-readable sentence. Some also carry code, a stable machine-readable reason — branch on that, never on the sentence, which is prose and gets reworded.

object
error
required
string
code

Present only on the failures worth branching on, and deliberately not an exhaustive enum: treat a code you do not recognise as if it were absent and fall back to the status code.

The ones that exist today:

  • credit_limit_reached — 402 from POST /services and POST /services/{serviceId}/change-plan. Your wallet, not the client’s: funding the purchase would take you past your overdraft (default 0, i.e. past zero). Top up; do not credit the client.
  • domain_disabled — 409 from a configuration write on a disabled domain (records, rules, cache, SSL, members, settings). The domain is read-only until POST /domains/{domainId}/enable.
  • unknown_rule_type — 404 from the rules paths when ruleType is not one of the documented values. You get this rather than an empty array, so a typo cannot read as a rule set that happens to be empty.
  • rate_limited — 429 from any route. Keyed per credential, so one runaway integration cannot lock its owner out of the dashboard.
  • session_check_failed — 503, and only on calls made with a dashboard session JWT. The session could not be verified, which is not the same as knowing it is revoked, so it is retryable and the session survives. Machine tokens never see this.
string
Example 
{
  "error": "forbidden",
  "code": "credit_limit_reached"
}

404

Section titled “404 ”

No such resource.

Media type application/json

Every error body carries error, a human-readable sentence. Some also carry code, a stable machine-readable reason — branch on that, never on the sentence, which is prose and gets reworded.

object
error
required
string
code

Present only on the failures worth branching on, and deliberately not an exhaustive enum: treat a code you do not recognise as if it were absent and fall back to the status code.

The ones that exist today:

  • credit_limit_reached — 402 from POST /services and POST /services/{serviceId}/change-plan. Your wallet, not the client’s: funding the purchase would take you past your overdraft (default 0, i.e. past zero). Top up; do not credit the client.
  • domain_disabled — 409 from a configuration write on a disabled domain (records, rules, cache, SSL, members, settings). The domain is read-only until POST /domains/{domainId}/enable.
  • unknown_rule_type — 404 from the rules paths when ruleType is not one of the documented values. You get this rather than an empty array, so a typo cannot read as a rule set that happens to be empty.
  • rate_limited — 429 from any route. Keyed per credential, so one runaway integration cannot lock its owner out of the dashboard.
  • session_check_failed — 503, and only on calls made with a dashboard session JWT. The session could not be verified, which is not the same as knowing it is revoked, so it is retryable and the session survives. Machine tokens never see this.
string
Example 
{
  "error": "forbidden",
  "code": "credit_limit_reached"
}

500

Section titled “500 ”

Something failed on our side. The body carries a human sentence and never an internal detail — a live sweep of this API once returned dial tcp 127.0.0.1:9000: connect: connection refused, which is our topology rather than an error message. That is now impossible.

Distinguish it from 503. A 503 means a dependency is down and the identical request will succeed later, so retry it. A 500 means the request hit a genuine fault: retrying it unchanged will fail the same way, and it should be reported with the X-Request-Id from the response header.

Declared on every operation because every operation can reach it. It was previously declared on exactly one, which left a generated client with no branch for the answer it is most likely to be surprised by.

Media type application/json

Every error body carries error, a human-readable sentence. Some also carry code, a stable machine-readable reason — branch on that, never on the sentence, which is prose and gets reworded.

object
error
required
string
code

Present only on the failures worth branching on, and deliberately not an exhaustive enum: treat a code you do not recognise as if it were absent and fall back to the status code.

The ones that exist today:

  • credit_limit_reached — 402 from POST /services and POST /services/{serviceId}/change-plan. Your wallet, not the client’s: funding the purchase would take you past your overdraft (default 0, i.e. past zero). Top up; do not credit the client.
  • domain_disabled — 409 from a configuration write on a disabled domain (records, rules, cache, SSL, members, settings). The domain is read-only until POST /domains/{domainId}/enable.
  • unknown_rule_type — 404 from the rules paths when ruleType is not one of the documented values. You get this rather than an empty array, so a typo cannot read as a rule set that happens to be empty.
  • rate_limited — 429 from any route. Keyed per credential, so one runaway integration cannot lock its owner out of the dashboard.
  • session_check_failed — 503, and only on calls made with a dashboard session JWT. The session could not be verified, which is not the same as knowing it is revoked, so it is retryable and the session survives. Machine tokens never see this.
string
Example 
{
  "error": "forbidden",
  "code": "credit_limit_reached"
}