200-901 Cisco Platforms and Development Practice Question

When using the Meraki Dashboard API, what HTTP header is used to pass the API key?

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

✓

X-Cisco-Meraki-API-Key: <key>

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

Answer analysis

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

✗
API-Key: <key>
Why it's wrong here
Meraki does not read an API-Key header; requests must send X-Cisco-Meraki-API-Key, so this returns 401. It is tempting because a plainly named custom header mirrors how many APIs accept static keys, and it would work on services that document a vendor-specific key header of that exact name.
✓
X-Cisco-Meraki-API-Key: <key>
Why this is correct
The Meraki Dashboard API authenticates each request by placing the API key in the X-Cisco-Meraki-API-Key request header. This satisfies the stem's requirement, since the key is passed as a custom HTTP header rather than a query string or bearer token.
✗
Authorization: Bearer <key>
Why it's wrong here
Meraki Dashboard API expects the key in the X-Cisco-Meraki-API-Key header, so Bearer tokens are rejected. It is tempting because Authorization: Bearer is the standard OAuth 2.0 pattern for REST APIs, and it would be correct for APIs that issue access tokens rather than a static per-organisation API key.
✗
Meraki-API-Key: <key>
Why it's wrong here
The header name is X-Cisco-Meraki-API-Key, not Meraki-API-Key, so the dashboard ignores it and rejects the call. It is tempting because it looks like the vendor-prefixed custom header Meraki documents, and a similarly named header would be correct on APIs that define their own key header without the X-Cisco prefix.

Go deeper