SearchFlights alongside POST /api/flights/search in enriched network output.
name and route are required. See Schema reference for the full type, including the Payload and Field sub-types and the properties, tags, environments, and origins fields described below.
Route patterns
Request routes use the same glob syntax as views:* matches one segment, and ** matches any depth. Express-style :param segments are normalized to *, so these routes are equivalent:
:param when the application already expresses the route that way. Consumers treat both forms identically.
Method filter
method is an optional, case-insensitive HTTP method filter such as GET, POST, or PUT. If omitted, the definition matches any method.
007-request-method-filter verifies that the optional method filters choose the matching definitions.
All matches apply
Requests are matched independently. Every definition whoseroute matches the URL and whose optional method matches the request method applies.
POST /api/flights/search matches both SearchFlights and AnyFlightsCall. Declaration order does not affect request matching.
View matching uses a different rule: exactly one view wins by specificity. See Views.
Payloads are documentary
request and response describe the expected payload shape. Both are Payload objects with an optional fields array. Each field requires a name and may include a free-text type and description. The type value is not restricted to a predefined set.
The listed fields are documentary, not exhaustive. They do not validate live request or response payloads.
headers lists header names that a consumer may highlight in network details. This example documents the response from a current-user endpoint:
Scoped vs global
Requests can be declared at the file root or inside a view.- Global requests at the file root are matched on every view.
- View-scoped requests are matched only when that view is active.
- The two scopes are additive: an active view receives its requests and all global requests. See Views.
Properties
properties names values to pull out of live traffic. An HTTP 200 does not tell an approved payment from a declined one when the outcome lives in the response body. Each entry has a name and an extract object:
pattern is an RE2 regex applied to the value path selects; capture group 1 is the value when the pattern has one. A property that doesn’t resolve is simply absent, never an error. Body and header properties need live traffic, so a static tool treats them as declared but unavailable.
A request route’s :name segments bind as properties exactly as a view’s do. status, method, and duration are reserved names for the request’s own HTTP identity: declaring a property under one shadows it (sightmap validate warns request-property-shadows-reserved), and a route binding with one of those names is an error.
The older
source: / field: / pattern: keys still load, lowered to extract, with an extract-legacy-form warning. They will be removed in a later release.properties and the request/response payloads answer different questions: payload fields document expected shape for a reader, while properties names a value to extract. See the schema reference.
Tags, environments, and origins
tags on a request resolve as a union across every matching request. environments names the deploy targets an endpoint exists in, and origins the hosts it is called on. A view-scoped request’s environments are intersected with its view’s, but its origins are not inherited, because a page and the APIs it calls usually live on different hosts. None of these change which traffic the route matches. See Environments and origins.
Next
Messages and signals covers console and exception patterns. Memory covers thememory: field that any request can carry, surfaced to the agent in the network-trace detail view.