Overview
Understanding and Using APIs is worth 20% of the 200-901 exam, tied with Infrastructure and Automation as the heaviest domain. It has nine objectives. Objective 2.1 asks you to construct a REST request from API documentation, and 2.2 covers webhook usage patterns. Objective 2.3 deals with constraints such as rate limits and pagination. Objectives 2.4 to 2.6 cover HTTP response codes, troubleshooting a failed call from its code, request and documentation, and reading the status line, headers and body. Objective 2.7 covers basic, custom token and API key authentication, 2.8 compares REST, RPC, synchronous and asynchronous styles, and 2.9 asks you to build a Python script with the requests library.
Many objectives use the verbs construct, troubleshoot and utilize, so expect applied items where you complete a request or diagnose a response rather than recall a definition.
How it's tested
Expect documentation excerpts, curl commands, Python requests code and raw HTTP responses. Questions ask you to fill in a missing method, header or parameter, explain a status code, or predict what a script prints. Fill-in-the-blank and drag-and-drop formats are common in this domain.
-
Complete the request
An API reference entry is shown with a partial curl or Python call, and you supply the method, path, header or body.
-
Diagnose the response
A request and its error response are shown, and you identify the cause and the correction from the status code and documentation.
-
Choose the style or mechanism
A use case is described, and you pick webhooks over polling, an authentication method, or a synchronous or asynchronous call.
A script sends a POST to create a network and receives 401 Unauthorized. The documentation says the API key must be sent in an X-Cisco-Meraki-API-Key header, while the script places it in a query parameter. A 401 means the server could not authenticate the caller, so the fix is moving the key into the documented header, not changing the body or permissions.
Objectives 9
Official objectives from the Cisco outline, in outline order.
2.1 Construct a REST API request to accomplish a task given API documentationTurning a documented endpoint into a working call.
- What it means
- A REST request combines a method (GET, POST, PUT, PATCH, DELETE), a URI made of base URL, resource path and optional query parameters, headers such as Content-Type, Accept and authorisation, and for create or update calls a body, usually JSON.
- What to understand
- Documentation tells you which method and path an action uses, which path variables to substitute, which query parameters filter results, and what schema the body follows. GET reads, POST creates, PUT replaces, PATCH partially updates and DELETE removes. Content-Type describes the body you send and Accept states the format you want back. Exam items often hide the answer in a single detail of the documentation table.
- How it shows up
- Fill a gap in a curl or Python call using a documentation excerpt.
- Common confusion
- Swapping Content-Type and Accept, or using PUT where the documentation specifies PATCH.
2.2 Describe common usage patterns related to webhooksEvent-driven callbacks from a service to your URL.
- What it means
- A webhook is a user-defined HTTP callback: you register a target URL with a service, and when a chosen event occurs the service sends an HTTP POST with event data to that URL.
- What to understand
- Webhooks replace repeated polling, reducing load and delivering events close to real time. The receiving application must be reachable from the sender, so local testing often uses a tunnel. Webex uses webhooks for new messages and membership changes, and Meraki can send alerts the same way. Receivers often validate a shared secret or signature to confirm the sender.
- How it shows up
- Choose webhooks over polling for event notification, or identify what the receiver must provide.
- Common confusion
- Thinking the client initiates the webhook call; the service sends it to you.
2.3 Describe the constraints when consuming APIsRate limits, pagination, payload limits and timeouts.
- What it means
- APIs impose limits to protect the service: rate limits cap requests per period, pagination returns large result sets in pages, and servers enforce maximum payload sizes and timeouts.
- What to understand
- When a rate limit is exceeded the server typically returns 429 Too Many Requests, often with a Retry-After header, and well-behaved clients back off before retrying. Pagination may use offset and limit parameters, page tokens or a Link header pointing to the next page, so a script that reads only the first response may miss data. Caching responses also reduces calls.
- How it shows up
- Explain why a script returns only part of a list, or what to do after a 429.
- Common confusion
- Treating a 429 as an authentication failure and resubmitting credentials.
2.4 Explain common HTTP response codes associated with REST APIsWhat the 2xx, 3xx, 4xx and 5xx classes signal.
- What it means
- Status codes are grouped by class: 2xx success (200 OK, 201 Created, 202 Accepted, 204 No Content), 3xx redirection, 4xx client errors (400, 401, 403, 404, 405, 409, 415, 429) and 5xx server errors (500, 502, 503, 504).
- What to understand
- The class tells you whose problem it is: 4xx means the request needs fixing, while 5xx means the server or something behind it failed. Memorise the specific meanings: 201 after creating a resource, 202 when work will finish asynchronously, 204 when there is no body, 401 for missing or bad credentials, 403 for authenticated but not permitted, 404 for a wrong path or resource, and 415 for an unsupported Content-Type.
- How it shows up
- Match a status code to its meaning or to the most likely cause.
- Common confusion
- Confusing 401 Unauthorized with 403 Forbidden.
2.5 Troubleshoot a problem given the HTTP response code, request and API documentationUsing all three clues together to find the fault.
- What it means
- Troubleshooting combines the returned code with the request that was sent and the documented contract, comparing method, path, headers, parameters and body field by field.
- What to understand
- Start from the code class, then look for the mismatch with the documentation: a 404 often means a typo or wrong ID in the path, 405 a wrong method, 400 a malformed or missing body field, 415 a missing Content-Type, and 401 a missing or expired token. For 5xx errors, the request may be correct and a retry or escalation is appropriate.
- How it shows up
- Given a failing call and a documentation snippet, choose the single change that fixes it.
- Common confusion
- Changing the payload when the status code points to authentication or the path.
2.6 Interpret the parts of an HTTP response (response code, headers, body)Reading the status line, headers and payload.
- What it means
- An HTTP response has a status line with version, code and reason phrase, a set of headers such as Content-Type, Content-Length, Location, Retry-After and Set-Cookie, and an optional body that usually carries JSON or XML.
- What to understand
- Headers carry metadata you need for the next step: Location gives the URL of a newly created resource, Retry-After says when to retry, Link may hold pagination, and Content-Type tells you how to parse the body. In Python, response.status_code, response.headers and response.json() map directly to these parts.
- How it shows up
- Identify which part of a shown response gives a requested piece of information.
- Common confusion
- Looking in the body for the new resource URL when it is in the Location header.
2.7 Utilize common API authentication mechanisms: basic, custom token, and API keysThree ways APIs identify the caller.
- What it means
- Basic authentication sends a Base64-encoded username:password in the Authorization header. Custom token schemes exchange credentials for a token, which is then sent on each call, often as Authorization: Bearer or in a vendor header. API keys are long-lived secrets issued by the platform and sent in a header or query string.
- What to understand
- Base64 is encoding, not encryption, so basic authentication requires HTTPS. Catalyst Center uses basic authentication to obtain a token from its token endpoint, then expects that token in an X-Auth-Token header. Meraki uses an API key or bearer token. Tokens expire, so scripts must handle renewal. Keys and tokens should be stored outside source code.
- How it shows up
- Pick the header that carries credentials for a described platform, or the two-step token flow.
- Common confusion
- Treating Base64-encoded credentials as encrypted.
2.8 Compare common API styles (REST, RPC, synchronous, and asynchronous)Resource-oriented versus action-oriented APIs, and blocking versus non-blocking calls.
- What it means
- REST models resources addressed by URIs and acted on with standard HTTP methods, and is stateless. RPC exposes procedures or actions that the client calls by name, as in JSON-RPC, XML-RPC, gRPC or NX-API's JSON-RPC mode. Synchronous calls wait for the result; asynchronous calls return immediately, often with 202 and a task ID or a callback.
- What to understand
- Choose synchronous APIs for quick reads and asynchronous ones for long operations such as device provisioning, where the client polls a task resource or receives a webhook. Catalyst Center intent API calls that change state return a task ID for later checking. REST and RPC can each be used synchronously or asynchronously, so the two pairs are independent choices.
- How it shows up
- Classify an API from its URL and payload, or choose async for a long-running job.
- Common confusion
- Assuming every API using HTTP and JSON is RESTful.
2.9 Construct a Python script that calls a REST API using the requests libraryUsing requests to send calls and handle responses.
- What it means
- The requests library offers functions such as requests.get, post, put, patch and delete, accepting url, headers, params, json or data, auth and verify arguments, and returning a Response object.
- What to understand
- Passing json= serialises a dictionary and sets Content-Type automatically, while data= sends a raw string or form data. params builds the query string. response.raise_for_status() raises on 4xx and 5xx codes, and response.json() parses the body. auth=('user','pass') or HTTPBasicAuth performs basic authentication. verify=False disables certificate checks, which suits only lab sandboxes.
- How it shows up
- Complete or debug a short requests script that reads, creates or updates a resource.
- Common confusion
- Sending a dict with data= and expecting JSON on the wire.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
HTTP methods
GET read, POST create, PUT replace, PATCH partial update, DELETE remove.
- Remember
- PUT and DELETE are idempotent; POST is not.
- Tested as
- Request construction items.
- Trap
- Using POST for every change.
-
201 vs 202 vs 204
Created, accepted for later processing, success with no body.
- Remember
- 202 signals an asynchronous job.
- Tested as
- Response interpretation.
- Trap
- Calling response.json() on a 204.
-
401 vs 403
Not authenticated versus authenticated but not allowed.
- Remember
- Fix credentials for 401, permissions for 403.
- Tested as
- Troubleshooting stems.
- Trap
- Regenerating a token for a 403.
-
429 Too Many Requests
Rate limit exceeded.
- Remember
- Honour Retry-After and back off.
- Tested as
- API constraint questions.
- Trap
- Retrying immediately in a loop.
-
Content-Type vs Accept
Format of the body sent versus format wanted back.
- Remember
- 415 often means a wrong or missing Content-Type.
- Tested as
- Header completion questions.
- Trap
- Swapping the two headers.
-
Basic authentication
Base64 username:password in the Authorization header.
- Remember
- Encoding only, so HTTPS is required.
- Tested as
- Authentication mechanism questions.
- Trap
- Calling Base64 encryption.
-
X-Auth-Token
Header carrying the Catalyst Center session token.
- Remember
- Token first comes from a basic-auth POST.
- Tested as
- Platform-specific auth items.
- Trap
- Sending it as a Bearer header.
-
Webhook
Service-initiated HTTP POST to a registered URL on an event.
- Remember
- Removes the need to poll.
- Tested as
- Event-driven scenarios.
- Trap
- Expecting the client to call the webhook.
-
Pagination
Large results split across pages.
- Remember
- Follow next links or page tokens.
- Tested as
- Missing-data scenarios.
- Trap
- Assuming one GET returns everything.
-
requests json= argument
Serialises a dict and sets JSON Content-Type.
- Remember
- data= does not set it.
- Tested as
- Script completion items.
- Trap
- Double-encoding with json.dumps plus json=.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Client error codes
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| 400 Bad Request | Malformed syntax or invalid body | Fix the payload | Blaming credentials |
| 401 Unauthorized | Missing or invalid credentials | Fix authentication | Changing user roles |
| 403 Forbidden | Identity known but not permitted | Fix permissions | Re-sending the same token |
| 404 Not Found | Path or resource does not exist | Check URL and IDs | Assuming the server is down |
Authentication methods
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Basic | Base64 credentials per request | Simplest; needs HTTPS | Thinking it is encrypted |
| Custom token | Credentials exchanged for a session token | Token expires and must be renewed | Hard-coding a token forever |
| API key | Platform-issued secret string | Long-lived; tied to an account or app | Committing keys to Git |
API styles
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| REST | Resources plus HTTP verbs | Noun-based URIs, stateless | Calling any HTTP API REST |
| RPC | Named procedures with parameters | Verb-based calls, often one endpoint | Expecting resource URIs |
| Asynchronous | Immediate reply, result later | 202 plus task ID or callback | Treating 202 as finished |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Status code fix
- What candidates pick
- Regenerate the API key after a 403
- Why it looks right
- Any access error feels like a credential problem
- Why it's wrong
- 403 means the caller was identified but lacks permission; a new key for the same account changes nothing.
Clue to watch for The response says Forbidden rather than Unauthorized.
-
Basic authentication security
- What candidates pick
- Basic authentication is safe because credentials are encoded
- Why it looks right
- Encoded text looks scrambled
- Why it's wrong
- Base64 is reversible by anyone, so credentials are exposed without TLS.
Clue to watch for Mention of HTTP rather than HTTPS.
-
Webhook direction
- What candidates pick
- The client polls the webhook URL
- Why it looks right
- Polling is the familiar pattern
- Why it's wrong
- With webhooks the service pushes an HTTP POST to the URL you registered.
Clue to watch for The stem says notify when an event occurs.
-
Long-running task
- What candidates pick
- Wait for a 200 with the final result
- Why it looks right
- Synchronous calls are simpler to reason about
- Why it's wrong
- The API returned 202 with a task ID, so the result must be fetched from the task resource later.
Clue to watch for A taskId or executionId in the body.
-
Partial results
- What candidates pick
- The API has a bug returning too few items
- Why it looks right
- The count looks wrong
- Why it's wrong
- The API paginates; the script must follow the next-page link or token.
Clue to watch for A Link header or nextPage field in the response.
Answer framework
Apply this sequence to any request-building or response-troubleshooting question in this domain.
- Read the documentation excerpt first and note the method, path, required path variables, query parameters and body schema it specifies.
- Check authentication next: which header or parameter carries the key or token, and whether a token must first be obtained with basic authentication.
- Compare the shown request with the documentation field by field and mark every difference in method, URL, header or body.
- Use the status code class to decide whose problem it is, then match the specific code to the difference you found.
- For scripts, confirm how requests is called, including json versus data, params, auth and verify, and what the script does with the Response object.
Practice question
Want more like this? The CCNA Automation practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Treat this domain as practical work. Open a free Cisco DevNet sandbox or the Meraki public API documentation and make real calls with curl, Postman and Python requests until building a request from a documentation page feels routine. Deliberately break each call: remove the token, mistype the path, drop the Content-Type header, use the wrong method. Record which status code each mistake produces, because the exam's troubleshooting questions are built on exactly these pairings.
Make a one-page table of status codes with cause and fix for each, and drill it until 401, 403, 404, 405, 415 and 429 are instant. Practise both authentication flows: basic authentication to get a Catalyst Center token, then an X-Auth-Token call, and a Meraki call with an API key. Write one short script that pages through a long result set and one that registers a Webex webhook. Then spend your final sessions on timed questions that mix documentation excerpts with code, since speed in reading these is what the 20% weight rewards.
FAQ
What share of the CCNA Automation exam is Understanding and Using APIs?
Understanding and Using APIs is 20% of the 200-901 exam, tied with Infrastructure and Automation as the largest domain, and it has nine official objectives.
Which HTTP status codes should I memorise?
At minimum 200, 201, 202, 204, 301, 400, 401, 403, 404, 405, 409, 415, 429, 500, 502, 503 and 504, with the likely cause and fix for each.
Do I need to know Postman?
Postman is not named in the objectives, but it is a convenient way to practise building requests and to export them as curl or Python code.
Which authentication methods are tested?
Objective 2.7 names basic authentication, custom tokens and API keys. Know where each is sent and why HTTPS is required for basic authentication.
Is the requests library the only Python HTTP library tested?
Objective 2.9 names requests specifically, so focus on its functions, arguments such as json, params, headers and auth, and the Response object.
How are webhooks tested?
Questions describe event notification scenarios and ask why a webhook beats polling, or what the receiving application must provide, such as a reachable URL.
Other Networking certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 2 knowledge
Work through API questions on status codes, authentication, webhooks and requests scripts to measure how ready you are for this 20% domain.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the CCNA Automation AI tutor Get any concept explained your way