200-901 Understanding and Using APIs Practice Question

When using the Meraki Dashboard API, how should the API key be included in a request?

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

In the X-Cisco-Meraki-API-Key header

Meraki requires the API key in a custom header X-Cisco-Meraki-API-Key.

Answer analysis

For each option: why learners choose it and why it is or isn't the right answer here.

✓
In the X-Cisco-Meraki-API-Key header
Why this is correct
Meraki Dashboard API authenticates every call by reading the key from the X-Cisco-Meraki-API-Key request header, not from a query string or bearer token. Supplying it there satisfies the stem's requirement, since the dashboard rejects requests lacking that exact header name.
✗
As a query parameter named 'apiKey'
Why it's wrong here
Meraki requires the key in the X-Cisco-Meraki-API-Key header; a query parameter named apiKey is ignored, producing a 401. Query-string keys are correct for APIs that explicitly document them, but they also leak credentials into logs and browser history.
✗
In the Authorization header using Bearer scheme
Why it's wrong here
Meraki authenticates with the X-Cisco-Meraki-API-Key header, not an OAuth2 Bearer token, so a Bearer Authorization header returns 401. Bearer tokens are correct for OAuth 2.0-protected APIs where a token is issued after a separate authorisation flow.
✗
In the request body as JSON
Why it's wrong here
Meraki's API expects the key in the X-Cisco-Meraki-API-Key header, so placing it in a JSON body leaves the request unauthenticated and rejected. Body credentials suit APIs that accept JSON login payloads, such as token endpoints, not Meraki's per-request key model.

Go deeper