A partner exposes a REST API and issues a separate API key to each of its customers, sent in a request header named X-Partner-Key. Several business units, each a different partner customer, will use one custom connector, and each unit must use its own key. Which authentication type should the developer configure?
Select an answer to reveal the explanation.
Short Explanation
The partner hands out keys, and each business unit has its own, so you want a connector that asks for the key when the connection's created. That's API Key auth with the header name the partner expects. Hard-coding one key in a policy means everyone shares one key, which is the opposite of the requirement.
Full Explanation
API Key authentication in a custom connector defines a parameter label, a parameter name and a location of header or query. Setting the name to X-Partner-Key with location header means the connector sends the value on every call, and because the value is supplied when each connection is created, every business unit's connection holds its own key. This matches an API that issues per-customer keys. Generic OAuth 2.0 requires an authorization server, client registration and token endpoints; using a static key as a client secret does not produce the header the API expects. Basic authentication sends an Authorization header with base64-encoded credentials, not an X-Partner-Key header, so the API would not recognize the key. A Set HTTP header policy with a fixed value applies the same key to every connection, so all business units would share one customer's key and its quota and audit trail. Exam caveat: the parameter name and location must exactly match what the API expects; the label is only what makers see when they create the connection. Operational check: create two connections with different keys, call an operation through each, and confirm the partner's logs attribute each call to the right customer.