Requests and rules

Auth headers, request bodies, and the content rules that judge a response.

Real endpoints are rarely bare public GETs: they want auth, sometimes a payload, and a 200 from them is not always proof of health. Three fields turn a URL check into a real probe: request headers, a request body, and content rules. All three live on the HTTP family (HTTP, Keyword, API); headers and bodies also work on schedulers.

#Request headers

Add up to 4 headers to every check the monitor sends. The form's auth picker covers the common shapes, a Bearer token or an API key header, and a custom mode covers everything else.

Header values are secrets and are treated like it: encrypted at rest, and write-only. The edit form never shows a stored value back; leave it untouched and the stored secret keeps being used, change it and the new value replaces it. Editing other fields never disturbs them.

#Request bodies

Write methods (POST, PUT, PATCH, DELETE) can carry a body of up to 8 KB. It is sent as application/json unless you set your own Content-Type header. GET and HEAD refuse a body.

The body is stored as plain text by design, it is a test payload you read and edit, so real secrets belong in the encrypted headers, not in the body.

The body is sent with every scheduled check

A monitor with a write method fires that write on your interval, all day, every day. Point it at test data or a dedicated test route, never at anything that mutates real customer state.

#Content rules

Content rules judge the response body, so a 200 that renders an error page still fails. Up to 4 per monitor, and because they need the body, setting any rule switches a HEAD monitor to GET automatically.

Rule	Passes when
Text contains	The body includes the text you set.
Text absent	The body does not include the text you set.
JSON field	The field at your dot path exists, and matches `equals` if you set it.

The mechanics that matter:

All rules must pass. One failing rule fails the check, and every rule is evaluated, so the event shows a verdict per rule, including what a JSON field actually contained versus what you expected.
JSON field paths are dot paths, like data.status. Leave the expected value empty and the rule only requires the field to exist. If the body is not valid JSON at all, the rule fails, which is itself a useful signal from an API.
JSON field rules are a paid feature. Text rules are free.

#Putting it together

An authenticated health probe, straight from the API, an auth header plus a rule pinning the real health signal:

curl -X POST https://upcheck-api-a.rekwiem.com/v1/monitors \
  -H "Authorization: Bearer upk_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://api.example.com/health",
    "request_headers": [{ "name": "Authorization", "value": "Bearer service-token" }],
    "content_rules": [{ "type": "json_field", "path": "status", "equals": "ok" }]
  }'

The same configuration is available field-for-field in the dashboard form and over MCP.