{
  "id": 8941445,
  "title": "I ran a contract check against the Swagger Petstore. Here is what came back.",
  "url": "https://urgent.news/2026/09/21/i-ran-a-contract-check-against-the-swagger-petstore-here-is-what-came",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-21T14:43:58.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/b6bs62fhysjpg/i-ran-a-contract-check-against-the-swagger-petstore-here-is-what-came-back-24me"
  },
  "original_language": "en",
  "account": "Most API bugs are not crashes, but small inconsistencies between the specification and the actual live API. These discrepancies can include missing fields, undocumented status codes, or unexpected body formats. To detect these issues, I created SpecSentinel, a simple command-line tool. It takes an OpenAPI specification and the URL of a running API, sends GET requests to each endpoint, and compares the responses against the specification. SpecSentinel exits with a 0 for a match, a 1 for drift (discrepancy), or a 2 if the check cannot be performed. I tested SpecSentinel using the public Swagger Petstore demo API, and here's what I found:\n\nThe GET /pet/findByStatus endpoint returned a 200 OK status, but there was a warning about the server error status code 500, which was only partially covered by the default response. The GET /pet/findByTags endpoint returned a 500 OK status, indicating a problem that SpecSentinel covered with a warning. The GET /user/login endpoint was documented as a JSON response, but the actual response was plain text, causing a drift error since a client trusting the spec would fail to parse it correctly.\n\nThree endpoints returned a 500 status code, but since the spec only covers server errors through its default response, SpecSentinel labeled these as warnings instead of errors. It's worth noting that the Swagger Petstore is a shared demo server, so results may vary over time. This isn't a complaint about the Petstore, but rather a testament to its real-world nature as a test case.\n\nCurrently, SpecSentinel only checks GET requests and JSON responses. However, I ran schema checks against the public specs of the Petstore, GitHub, and Stripe (920 GET operations) to ensure the tool doesn't raise false alarms on large real-world specifications. When fed with generated conforming examples from each schema, the checker produced no findings and no crashes, demonstrating its reliability without false alarms.\n\nSpecSentinel does not yet check for string formats, lengths, number ranges, patterns, or required response headers, and it doesn't output JSON for other tools. The latest version (0.2.0) adds warnings for these features, JSON output for other tools, and a one-line GitHub Action integration. To try the tool on your own API, install it using `pip install specsentinel`. If you encounter issues or have suggestions for improvement, please share your feedback; this input will help make SpecSentinel better for everyone.",
  "summary": "Most API bugs I care about are not crashes. They are small lies between the spec and the live API. A field that went missing. A status code nobody documented. A body that is not what the spec says it is. I built SpecSentinel to catch those. It is a small command line tool. You give it an OpenAPI spec and the address of a running API. It sends GET requests, compares every answer with the spec and…",
  "key_points": [
    "SpecSentinel detects API inconsistencies between spec and live API",
    "Swagger Petstore test reveals 500 status warnings for 3 endpoints",
    "Tool lacks checks for string formats, lengths, number ranges"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}