In a Postman collection, why put a brace token in the oauth2 accessToken attribute instead of pasting a credential?
answer
- One holds a value, the other a name
- Decided when typed, or decided per request
- What the exported file ends up carrying
- The script keeps the promise the placeholder makes
- Both halves must spell the same key
basics
~20 sA brace token binds late: the exported file carries only a variable name, and whatever a pre-request script most recently stored under it signs the next request. A pasted credential is frozen into the file and goes stale.
solid answer
~40 sLate binding. The `accessToken` attribute can hold either the credential itself or `{{access_token}}` — the *name* of a variable. With the name, the collection file carries nothing sensitive, and the value is decided per request rather than when someone typed it: the runtime resolves variables into the auth just before the handler signs, so the freshest thing a `prerequest` script wrote is what goes out. A pasted credential has none of that — it ships inside the file, it cannot be refreshed without a human editing and re-exporting, and every request fails once it expires. The one rule the indirection imposes is that both halves spell the same name; a mismatch signs the request with the literal placeholder and the server refuses it.
code
json · 6 lines{
"type": "oauth2",
"oauth2": [
{ "key": "accessToken", "value": "{{access_token}}", "type": "string" }
]
}go deeper
Be ready to say that the double-brace value is a variable name, that a script fills it, and that the alternative pastes a real credential into a file you may share.
Explain that resolution happens per request, immediately before signing, which is why the most recent value a script wrote is the one that goes out.
Know the silent failure: a misspelled key is signed with the literal placeholder and refused by the server, with no error raised by the collection itself.
Own the convention that collection files never carry live credentials, and that acquisition and consumption are joined only by an agreed variable name.
## Two ways to fill one attribute A collection's `auth` object declares a `type` and, under a key of the same name, an array of `{key, value}` attributes. For `oauth2`, the attribute the runtime's handler reads is `accessToken`. You can put two very different things in its `value`: - **A pasted literal** — the actual credential, written into the file. - **A brace token** — `{{access_token}}`, the *name* of a variable that will hold the credential later. The second is late binding, and it is the whole reason a collection can fetch its own token. ## What each one means for the file | | Pasted literal | Brace token | |---|---|---| | What the exported file contains | the credential itself | a variable name | | When the value is decided | when someone typed it | at send time, per request | | Who can refresh it | a human, by editing and re-exporting | a `prerequest` script, silently | | What happens when it expires | every request fails until edited | the next fetch replaces it | | What sharing the collection shares | the credential | nothing sensitive | ## When the substitution happens The runtime does not hand the handler a brace token. Before the request is sent it rebuilds both the item and the auth with variables resolved, and only then does the `oauth2` handler's `sign` read `accessToken` and add the value to the request. So the sequence for one request is: 1. The `prerequest` script runs and writes the freshest token into a scope, using `pm.environment`, `pm.collectionVariables` or `pm.globals`. 2. The runtime resolves variables into the item and the auth. 3. The handler signs with whatever came out of step two. Because step two runs for **every** request, the value the handler sees is always the most recent thing the script wrote. That is what "late binding" buys: the credential is looked up fresh rather than baked in. ## The failure that looks like nothing If the script writes `token` and the attribute says `{{access_token}}`, the placeholder is not replaced — and it is still a non-empty string, so the handler happily signs with it. The request goes out and the server refuses it. There is no error from the collection itself, which is why the first check when a signed request is rejected is that the script's key and the attribute's brace token spell the same name. ## Rules of thumb - Put a name in the attribute, and let something else decide the value. - Keep that name identical on both sides — the script that writes it and the auth block that reads it. - Do not paste a live credential into a file you are going to share or commit. - If nothing writes the variable, nothing signs correctly; the brace token is a promise the script has to keep.
- If nothing ever writes the variable named by the brace token, what does the request look like on the wire?It is still signed, with the placeholder text as the credential. The handler bails out only when `accessToken` is falsy, and an unsubstituted `{{access_token}}` is a non-empty string, so the value reaches the request and the server rejects it. Nothing in the collection reports an error, which makes a key typo look like an authorization problem on the server's side.
- Which scope should the pre-request script write the token into?One the run still holds when the request is prepared — `pm.environment`, `pm.collectionVariables` or `pm.globals` all qualify. The value has to outlive the script's own execution, because resolution into the auth happens afterwards, in the step that prepares the request for sending.
saying these in an interview costs you the question
- Thinks pasting the credential is fine because the file stays private
- Believes the placeholder is replaced once, when the file is loaded
- Assumes an unwritten variable makes the request go out unsigned
- Expects the collection to error when the variable name is misspelled
- Cannot say who is responsible for putting the value under the name