A retailer with branch stores calls an inventory API that accepts only a bearer token, while the synthetic test still submits a form password and is rejected. What should the test present?
Select an answer to reveal the explanation.
Short Explanation
An API that checks a bearer token is like a door that accepts one kind of keycard. You configure the retailer's synthetic test to present that bearer token. A form password, an anonymous call, or a loss probe that does not sign in will not satisfy the API.
Full Explanation
The synthetic transaction has to authenticate the way the target authenticates. This inventory API accepts a bearer token and rejects the form password the test is sending, so the test must present the bearer token. A form username and password may be how people sign in to the store portal, and it is a different method than the API under test. Calling the API with no credentials and treating any HTTP response as success hides an authentication failure inside a vague status, or scores an error page as a healthy transaction. A network-loss probe that does not authenticate can show loss on the path to the store, and it never presents a token or proves the API accepted the client. Exam caveat: a rejection of the wrong credential is a test configuration fault, not proof that the inventory service is down for the branches. Operational check: run the transaction with the bearer token the API expects and confirm it reaches the same inventory response a branch application receives. If the test still posts a form password, it is not exercising the API's login.