Monitoring an API endpoint

A GET request to a health endpoint tells you the server answers. It does not tell you the API accepts and processes a request. Vantield monitors can send a real POST or PUT with a body and check what comes back.

Set up a POST monitor

  1. Create a monitor and set HTTP method to POST. POST is available on every plan, including Free. PUT and HEAD are available on Enterprise.
  2. Open Request Body, choose a Content-Type, and enter the body.
  3. Set Expected status code to the code a successful call returns, such as 200, 201, or 204.
  4. Optionally add a Response body match - a string that only appears in a correct response.
  5. Save, then use Check Now to confirm the monitor passes.

Supported Content-Types

  • application/json
  • application/x-www-form-urlencoded
  • application/xml
  • text/plain

Request bodies can be up to 64 KB.

Example

A search endpoint that should return results for a known query:

Method:          POST
URL:             https://api.example.com/v1/search
Content-Type:    application/json
Body:            {"query": "status-check", "limit": 1}
Expected status: 200
Body match:      "results"

This monitor fails if the API returns an error code, responds slower than your timeout threshold, or returns a 200 without a results field - for example an empty error page served by a proxy.

Choosing a safe endpoint

A monitor sends its request on every interval - up to 1,440 times a day at a 1-minute interval. Point it at an endpoint where repeating the request is harmless:

  • Read-style endpoints that happen to use POST, such as search or validation.
  • A dedicated health or echo endpoint that exercises the same code path as real traffic.
  • A test-mode endpoint that does not create real records, send emails, or charge cards.
Custom request headers, such as an Authorization header, are not configurable today. Monitor endpoints that do not require authentication, or expose a public health endpoint that checks the authenticated path internally.

Validating the response

CheckCatches
Expected status code (exact match)Errors, unexpected redirects, and auth failures.
Response body match (case-sensitive, first 10 KB of the body)A 200 that serves the wrong content: maintenance pages, cached error pages, empty results.
Response timeout threshold (5-45 seconds)Responses that succeed but too slowly to be useful. The actual response time is still recorded.
SSL certificate verificationExpired or invalid certificates.

Debugging a failed check

On Pro and Enterprise, every failed check stores the request headers sent, the response headers received, and up to 10 KB of the response body. Open the failed check on the monitor detail page to see the exact exchange without reproducing it.

Next: Alerts and notifications