After a successful FDM token response, which header correctly authenticates a subsequent POST or DELETE to /object/networks?
Select an answer to reveal the explanation.
Short Explanation
The access_token is the badge you clip on for every object call. The refresh token is a later token-hop tool, not something you slap onto /object/networks.
Full Explanation
After FDM returns a successful token response, subsequent POST or DELETE calls to /object/networks authenticate with Authorization: Bearer carrying the access_token value from that response. The access_token is the short-lived API credential for the REST session; object and operational endpoints expect that header construction rather than UI session tricks.
Copying a Cookie from an FDM UI browser login fails the API pattern: browser session cookies are for interactive UI affinity, not the documented token-based REST client path, and they break headless civic scripts. Putting the refresh_token into Authorization: Bearer fails because refresh tokens exist to obtain new access tokens at the token endpoint; they are not accepted as if they were access tokens on object URLs. Sending X-Username with a cleartext admin username and no Bearer fails authentication design—FDM REST for this task does not substitute a custom username header for the Bearer access_token.
Exam caveat: confuse access_token vs refresh_token once and every object call fails with 401 even though “you have a token field in JSON.”
Operational check: parse access_token only into the Bearer header, make a read call, then on 401 POST the token endpoint again (using refresh or password grant per your client design) and retry—never send refresh_token on /object/networks.