Response assertions

A 200 status code is rarely enough. DevFlow lets you assert on the shape of a response — schema, fields, headers, latency.

status and latency

assertions:
  - status_eq: 200
  - latency_lt_ms: 800

Both available on every monitor. status_in: [200, 204] works too.

headers

assertions:
  - header_eq:
      name: Content-Type
      eq: application/json
  - header_present: X-Request-Id

JSONPath

assertions:
  - body_jsonpath:
      path: $.status
      eq: ok
  - body_jsonpath:
      path: $.data.user.id
      type: string

type accepts string, number, boolean, array, object, null.

JSON-Schema

For a fuller contract, supply a JSON-Schema:

assertions:
  - body_json_schema:
      schema_ref: workspace://schemas/charge-response-v3.json

Schemas can be uploaded with the CLI:

devflow schema push ./schemas/charge-response-v3.json

regex

assertions:
  - body_regex_matches: "^OK \\d{4}$"

Use sparingly — JSON-Schema or JSONPath nearly always says it better.

negation

Every assertion supports negate: true if you want "this must NOT match".

strictness vs flapping

Be honest about which fields are stable. If a payload includes a generated request_id, assert on its presence with type: string, not its value. The biggest cause of troubleshooting-flapping-monitors is over-strict assertions.