Practise API documentation writing: endpoint descriptions, parameter descriptions, error messages, and code example narration.
0 / 10 completed
1 / 10
Which endpoint description follows API documentation best practices?
Good API endpoint descriptions: start with a verb (Retrieves), explain what is returned (paginated list of users), mention filters (by role), and note requirements (authentication).
2 / 10
A parameter description for 'limit: integer' should specify:
Good parameter descriptions include: what it controls (results per page), default value (20), constraints (maximum 100), and implicit information (it is for pagination).
3 / 10
Which error response message is most helpful to the API consumer?
Helpful error messages: specify the HTTP status, identify the problematic field (email), explain the validation rule (valid email address), and show what was received.
4 / 10
In API documentation, a 'code example' should:
The most useful code examples: complete (both request and response), realistic (not placeholder values), and focused on the most common use case.
5 / 10
Which sentence best introduces a code example in API documentation?
A clear introduction to a code example explains what it shows (retrieves), the filter (active users), and the sorting — so readers understand the example before reading the code.
6 / 10
During a code review of the User service API, Sarah notices that the endpoint documentation for retrieving user profiles doesn't clearly state what fields are returned by default. Which of the following descriptions would be most helpful to David, the developer who wrote the endpoint?
The core issue here is clarity. Option 2 reflects best practice - explicitly stating the default response schema avoids ambiguity and reduces the burden on the consumer. Options A and D are too vague or misleading; option B doesn't address the specific concern raised about the default fields. It's crucial to highlight what's readily available without requiring extra requests.
7 / 10
You are drafting a Slack message to your team explaining the new rate limiting policy for the Payment API. A junior developer, Mark, is struggling to understand how this impacts his code. Which of the following messages best conveys the information?
Effective communication in a Slack environment demands brevity and clarity. Option C is too technical for a junior developer. Option A is useless; option D provides the necessary information: the rate limit itself and the consequences of exceeding it. Providing a link to further documentation is also standard practice.
8 / 10
You're writing a PR description for an update to the API documentation for the Inventory service. The change adds a new parameter, 'category: string', which allows users to filter inventory items by category. Which of the following sentences is most effective in describing this parameter within the PR?
The PR description should prioritize understanding for users. Option A is too generic; option D focuses on implementation details irrelevant to the user. Option B provides both the definition *and* an example, which dramatically improves comprehension and allows developers to quickly integrate the new functionality.
9 / 10
During a standup meeting, you're discussing changes to the API documentation for the Orders service. You need to briefly explain that developers can now retrieve order details by their unique ID. Which of the following statements would be most appropriate?
Standup updates require clear and accessible language. Option A is too complex; option C sounds overly bureaucratic. Option D provides the simplest possible explanation – focusing on what developers *do* with the information, rather than technical jargon. The phrasing highlights the core functionality in a way that's easily digestible.
10 / 10
You are reviewing a code example provided with the API documentation for the Products service. The example uses a complex query to filter products based on multiple criteria. Which of the following statements best describes how this code example should be presented within the documentation?
A good code example needs to be accessible. Option A is overwhelming; option D only provides a snippet without context. Option C lacks any explanatory information. Offering a brief explanation and demonstrating how the example fits into a larger workflow significantly increases its value for developers.
This exercise, "Writing for API Documentation", tests your understanding of technical writing vocabulary and phrasing through 10 multiple-choice questions drawn from real workplace scenarios.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one presents a realistic sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Who is this Technical Writing exercise for?
It's designed for IT professionals and learners who want to sound natural discussing technical writing topics in English — useful for meetings, documentation, interviews, and day-to-day communication with English-speaking teams.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more Technical Writing exercises?
Browse the full Technical Writing exercises hub for more practice, or explore other exercise categories covering vocabulary, grammar, interviews, and workplace communication.