A short piece of fiction, written by API Evangelist. The reader is imagined; the post, and every number and quotation from it, is real: "Grade An API From Zero To One Hundred And Check Which Dimensions Were Actually Scored," Kin Lane, November 6, 2026, https://apievangelist.com/2026/11/06/grade-an-api-from-zero-to-one-hundred-and-check-which-dimensions-were-actually-scored/
Marisol was eating lunch at her desk when a colleague dropped the link into the platform channel. She maintains the CI checks for her company's API repositories, and the checks produce a lot of lint output that nobody reads. She opened the post expecting a sales pitch.
The first line made her sit up. "A lint report is a list." She had a folder of them. The post's example was two hundred and forty-two diagnostics on a three-operation Petstore, accurate and useless to the person deciding whether the API was ready. That was exactly what her release managers said to her every quarter, in politer words.
She liked the idea of one number, a letter, and a breakdown to argue with. She liked it more when she saw how the Petstore got its 87. The design score was a density of warnings per governed node, and the documentation score honestly admitted that the example had no description, no contact and no tags. She could picture putting that breakdown in a pull request.
Then she hit the part the author said to read first, and her mood shifted. With an APIs.json alongside, the Petstore fell to a D because the scorecard failed to read the file's common block. The OWASP profile was accepted and ignored. Worst was the production contract, which came back a perfect 100 with only two dimensions, because the lint step had thrown an error that the scorecard swallowed. The post says it plainly: "An A with no lint is not an A."
She felt two things, and she didn't try to reconcile them. Part of her respected a tool's author for publishing its own failures in the same post that sells it. Part of her was uneasy. Her reviewers were already tempted to treat any number as settled, and a letter grade in a pull request would be read as a verdict. If the tool could hand a clean A to a document it never fully checked, how many of her colleagues would ever look at the dimensions underneath? She suspected the answer was none, and she did not think a free tool or a promised fix changed that. The post said both bugs were on the list to be fixed. She noted that as a promise, not a fact.
Still, the habit the post recommended was small, and it was hers to adopt. It said to "count the dimensions array before trusting overall". Three or six was the expected shape, and two meant something was skipped. She didn't have to trust the scorecard to do that. She only had to distrust it in a particular, checkable way.
She didn't wire the scorecard into every repository. She didn't even argue for it in the channel. She picked one low-stakes internal service, copied the curl command from the post, and ran it against that service's OpenAPI file by hand. The result had three dimensions, which was the expected shape. The overall was a C, driven mostly by documentation, which stung a little because she had written that documentation.
Then she opened a scratch branch and wrote a short script that called the endpoint, counted the entries in the dimensions array, and exited with an error if there were fewer than three. She didn't add it to the pipeline yet. She pushed the branch, left a note to herself to revisit it once the post's two bugs were fixed, and went back to her lunch.