2.3API
What it checks#
An API monitor sends one HTTP request and checks the response, like a URL monitor. It has the same form and the same assertions. It can also use team secrets. A team secret is a saved password or token that you refer to by name (chapter 8). Your plan must include API monitors.
When it is up, degraded or down#
- Up, degraded and down work as for a URL monitor (2.2).
- A secret that cannot be sent makes the check down. Examples:
secret NAME has no allowed sites,secret NAME is only sent over https,secret NAME is not allowed on <host>. - A redirect to a site the secret is not allowed on is not followed:
redirect not followed: secret NAME is not allowed on <host>.
Configuration#
The fields and defaults are the same as for a URL monitor (2.2). The form adds this hint: Write ${NAME} in the URL, a header value or the body to use a team secret. It is sent only over https to the secret's allowed sites.
| Dashboard field | Default | Limits and notes |
|---|---|---|
| name | Empty | Required. Up to 200 characters, on one line. |
| check interval | 60 seconds | At least 1 second. Your plan's minimum interval still applies: below it the form shows Your plan checks at most every N seconds. |
| timeout | 10 seconds | In seconds. A value above 60 seconds counts as 60 seconds. |
| locations | None (runs from us-west) | Choose from the regions shown. The check runs from each one you pick. |
| on failure — notify | None (all team channels) | Pick channels to limit who is alerted. Shown only when your team has channels. |
| request (method, URL) | GET, empty | As for URL. The URL may contain ${NAME}. |
| headers | None | Up to 50. Values may contain ${NAME}. |
| body | Empty | May contain ${NAME}. |
| assertions | status_code eq 200 | Every assertion must pass. Up to 50. |
Assertions supported#
The same as URL monitors (2.2). json_schema checks the whole JSON body against a JSON Schema. It works on URL, API and multi-step API monitors only.
Example#
Call an orders endpoint with a token saved as the team secret ORDERS_API_TOKEN. Check the shape of the reply.
| Field | Value |
|---|---|
| request | GET https://api.acme.io/v1/orders |
| headers | Authorization : Bearer ${ORDERS_API_TOKEN} |
| assertions | status_code eq 200json_schema with the schema below |
{
"type": "object",
"required": ["id"],
"properties": {"id": {"type": "integer"}}
}API=https://www.obsrvly.com/api/gw/monitor/obsrvly.v1.MonitorConfigService
curl -s "$API/CreateApiMonitor" \
-H "Authorization: Bearer $OBSRVLY_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "orders",
"url": "https://api.acme.io/v1/orders",
"headers": {"Authorization": "Bearer ${ORDERS_API_TOKEN}"},
"intervalSeconds": 60,
"assertions": [
{"type": "status_code", "op": "ASSERTION_OP_EQ", "value": "200"},
{"type": "json_schema",
"value": "{\"type\":\"object\",\"required\":[\"id\"]}"}
]
}'Without a plan that includes API monitors, the call fails with plan does not allow this monitor type: API monitors require Pro or Business.
Good to know#
- A secret is sent only over https, and only to the sites you allowed for it (chapter 8).
- Messages show
${NAME}, never the secret's value. - If a secret cannot be used at all, the result is could not run, with a message that starts
secret NAME cannot be used. - To create many API monitors at once from an OpenAPI spec, see 2.15.