In a Postman SDK proxy entry, what does the match property express and in what form is it written?

juniorshould knowfreq 46%

answer

Three parts, one string
Borrowed from browser extension manifests
One part is mandatory and often forgotten
A scheme spelling covers both at once
Wildcards a leading host label only

basics

~20 s

The match property names which URLs a proxy entry claims, written as one Chrome-grammar URL match pattern of scheme, host and path, such as https://.example.com/. It is not a regex and not a bare hostname.

solid answer

~40 s

In the Postman SDK a proxy entry is a ProxyConfig, and its match property holds a single URL match pattern in Chrome's extension grammar: <scheme>://<host><path>, for example https://*.example.com/*. The scheme is http, https, or Postman's http+https spelling covering both; the host may be a full host, *, or *. plus a domain suffix; the path is required and usually ends in *. It is not a regular expression, not a comma-separated hostname list, and not a priority signal — a narrower match does not outrank a broader one. match is also consulted only after the entry's bypass list has been checked and missed, so a correct match can be entirely irrelevant to the outcome.

In the Postman SDK a proxy entry is a `ProxyConfig`, and its `match` property holds a **single URL match pattern in Chrome's extension grammar**: `<scheme>://<host><path>`, for example `https://*.example.com/*`. The scheme is `http`, `https`, or Postman's `http+https` spelling covering both; the host may be a full host, `*`, or `*.` plus a domain suffix; the path is **required** and usually ends in `*`. It is not a regular expression, not a comma-separated hostname list, and not a priority signal — a narrower `match` does not outrank a broader one. `match` is also consulted only after the entry's `bypass` list has been checked and missed, so a correct `match` can be entirely irrelevant to the outcome.

code

json · 5 lines

json

{
  "host": "proxy.internal",
  "port": 8080,
  "match": "https://*.example.com/*"
}

go deeper

for a junior

Be ready to write a valid pattern out loud: scheme, then host, then path, as in https://.example.com/, and to say it is not a regular expression.

for a middle

Explain the grammar's rules and their failure modes: the mandatory path, the leading-label host wildcard, and the http+https spelling that covers both schemes.

for a senior

Show where the property sits in the wider decision — consulted only after the bypass check misses, and never as a specificity ranking between competing entries.

for a principal

Own the review angle: patterns in this grammar fail silently when malformed, so decide how proxy entries are reviewed and validated before they reach a shared configuration.

What the property holds

In the Postman SDK (postman-collection), a proxy entry is a ProxyConfig, and its match property holds a single URL match pattern in Chrome's extension grammar — the same <scheme>://<host><path> form browser extensions use to declare which pages they may touch. It is one pattern, not a list, and not a free-form expression.

match answers exactly one question: of the URLs this entry could serve, which ones does it claim? It does not decide on its own whether a request is proxied — it is consulted only after the entry's bypass list has been checked and found not to cover the URL.

The grammar, part by part

Part	What it accepts	Example
scheme	`http`, `https`, or Postman's `http+https` covering both	`http+https://`
host	a full host, `` for any host, or `.` plus a domain suffix	`*.example.com`
path	required; a literal path, usually ending in `*`	`/api/*`

Put together, a realistic entry looks like https://*.example.com/* or http+https://*/*.

Three rules are worth memorising because each of them produces a pattern that quietly matches nothing:

The path part is not optional. https://api.example.com is not a usable pattern; write https://api.example.com/*.
The host wildcard only replaces a leading label. *.example.com covers subdomains; api.*.com is not how the grammar wildcards a host.
The scheme is significant. A pattern written for https does not cover the http call to the same host. Use the http+https spelling when the entry is meant to cover both.

What it is not

Not a regular expression. * is a wildcard in this grammar, not a quantifier, and there is no anchoring, alternation or character class.
Not a bare hostname list. example.com on its own does not parse as a pattern; the scheme and path parts are structural, not decoration.
Not a comma-separated string. One ProxyConfig carries one match pattern; covering several unrelated hosts means either a broader pattern or several entries.
Not a priority signal. A more specific match does not outrank a less specific one — selection among entries is positional, not specificity-based.

Where it sits in the decision

For a single entry, the order is fixed: the bypass patterns are tested first, and only if none of them covers the URL is match consulted. So a perfectly written match can be entirely correct and entirely irrelevant, because something in bypass already answered.

That ordering is why "widen the match" is the wrong first response to a call that is not being proxied. If a bypass pattern covers the URL, no amount of widening reaches the code path where match is read.

Common mistakes when writing one

Writing the pattern for the host you were told about rather than the URL the request actually sends, including its scheme and path.
Assuming https://*/* covers plain-HTTP calls, which it does not.
Copying a hostname out of a browser address bar, complete with a path that then narrows the pattern to one endpoint.
Treating * inside a host label as meaningful — the grammar wildcards the leading label, not arbitrary substrings.

Why interviewers ask it

The property looks like a text field and behaves like a small language with rules of its own. A candidate who can state the three parts, name the http+https scheme spelling, and place match after bypass in the evaluation order has understood the entry as code rather than as a settings screen — which is exactly the difference that shows up when a proxy configuration misbehaves.

## What the property holds In the Postman SDK (`postman-collection`), a proxy entry is a **`ProxyConfig`**, and its `match` property holds a **single URL match pattern in Chrome's extension grammar** — the same `<scheme>://<host><path>` form browser extensions use to declare which pages they may touch. It is one pattern, not a list, and not a free-form expression. `match` answers exactly one question: *of the URLs this entry could serve, which ones does it claim?* It does not decide on its own whether a request is proxied — it is consulted only after the entry's `bypass` list has been checked and found not to cover the URL. ## The grammar, part by part | Part | What it accepts | Example | |---|---|---| | scheme | `http`, `https`, or Postman's `http+https` covering both | `http+https://` | | host | a full host, `*` for any host, or `*.` plus a domain suffix | `*.example.com` | | path | required; a literal path, usually ending in `*` | `/api/*` | Put together, a realistic entry looks like `https://*.example.com/*` or `http+https://*/*`. Three rules are worth memorising because each of them produces a pattern that quietly matches nothing: 1. **The path part is not optional.** `https://api.example.com` is not a usable pattern; write `https://api.example.com/*`. 2. **The host wildcard only replaces a leading label.** `*.example.com` covers subdomains; `api.*.com` is not how the grammar wildcards a host. 3. **The scheme is significant.** A pattern written for `https` does not cover the `http` call to the same host. Use the `http+https` spelling when the entry is meant to cover both. ## What it is not - **Not a regular expression.** `*` is a wildcard in this grammar, not a quantifier, and there is no anchoring, alternation or character class. - **Not a bare hostname list.** `example.com` on its own does not parse as a pattern; the scheme and path parts are structural, not decoration. - **Not a comma-separated string.** One `ProxyConfig` carries one `match` pattern; covering several unrelated hosts means either a broader pattern or several entries. - **Not a priority signal.** A more specific `match` does not outrank a less specific one — selection among entries is positional, not specificity-based. ## Where it sits in the decision For a single entry, the order is fixed: the `bypass` patterns are tested first, and only if none of them covers the URL is `match` consulted. So a perfectly written `match` can be entirely correct and entirely irrelevant, because something in `bypass` already answered. That ordering is why "widen the `match`" is the wrong first response to a call that is not being proxied. If a bypass pattern covers the URL, no amount of widening reaches the code path where `match` is read. ## Common mistakes when writing one - Writing the pattern for the **host you were told about** rather than the **URL the request actually sends**, including its scheme and path. - Assuming `https://*/*` covers plain-HTTP calls, which it does not. - Copying a hostname out of a browser address bar, complete with a path that then narrows the pattern to one endpoint. - Treating `*` inside a host label as meaningful — the grammar wildcards the leading label, not arbitrary substrings. ## Why interviewers ask it The property looks like a text field and behaves like a small language with rules of its own. A candidate who can state the three parts, name the `http+https` scheme spelling, and place `match` *after* `bypass` in the evaluation order has understood the entry as code rather than as a settings screen — which is exactly the difference that shows up when a proxy configuration misbehaves.

Why does the pattern https://api.example.com fail to cover that host's requests?
Because the path part of the grammar is not optional. A pattern needs a path component, so the usable form is `https://api.example.com/*`. Written without one, the pattern does not express what the author intended, and the entry ends up claiming nothing it was meant to claim.
How do you write one entry that covers both http and https calls to a host?
Use Postman's `http+https` scheme spelling, as in `http+https://api.example.com/*`. A pattern written for a single scheme covers only that scheme, so an https-only pattern silently misses the plain-HTTP call to the same host — a common cause of one endpoint being proxied and another not.

saying these in an interview costs you the question

Calls the match pattern a regular expression
Writes a bare hostname as the pattern value
Omits the path part of the pattern
Assumes an https pattern covers http calls too
Believes a narrower match outranks a broader one

In a Postman SDK proxy entry, what does the match property express and in what form is it written?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

What the property holds

The grammar, part by part

What it is not

Where it sits in the decision

Common mistakes when writing one

Why interviewers ask it

▾common follow-ups2 questions

▾red flags5 flags

What the property holds

The grammar, part by part

What it is not

Where it sits in the decision

Common mistakes when writing one

Why interviewers ask it

answer

go deeper