verify-api
Compare provider DTOs and WireMock test payloads with live responses from the real public API (currently NBP), and capture real responses as test fixtures. Use when adding or changing DTOs, when a Wir
SKILL.md.claude/skills/verify-api/SKILL.md
GitHubVerify DTOs against the live API
Goal: our DTOs and test payloads must match what the API really returns, so that a "passing" WireMock test means the client works in production.
Steps
List the endpoints to check. Take the URL builders (
src/OpenUrzednik.Nbp/UrlBuilder/NbpUrlBuilderFactory.cs,NbpUrlBuilder.cs) and the DTOs insrc/<Provider>/Dto/. Narrow to$ARGUMENTSif given.Call the real API with the read-only
curl -sand?format=json. For NBP, cover:- every table (
a,b,c) for bothexchangerates/tables/{t}andexchangerates/rates/{t}/{code} cenyzlota- each URL shape: latest,
last/{n},today,{date},{from}/{to} - error cases: a future date, an out-of-range
last/{n}(> 255 for rates and gold prices, > 67 for tables A and C, > 14 for table B), a date with no publication (weekend), a too-long range. Record the status code and the body text (NBP returns plain-text messages such as400 BadRequest - Błędny zakres dat).
Keep the request count low: NBP is a public service, so don't loop or hammer it.
- every table (
Compare with the DTOs:
- A
requiredproperty missing from any real response is a bug: deserialization will fail. - Report extra fields we ignore, type mismatches (number vs string, date formats) and casing.
- A
Compare with the WireMock tests in
tests/OpenUrzednik.IntegrationTests/<Provider>/WireMock/. Flag every hand-written body that differs in shape from the real one.Capture fixtures when asked, or when fixing a mismatch: save real bodies under
tests/OpenUrzednik.IntegrationTests/<Provider>/Fixtures/<endpoint-shape>.json(trim long arrays to 2–3 items, keep the real structure) and load them in the WireMock tests instead of inline JSON.Report a table: endpoint | status | fields in response | DTO verdict (OK / missing required / extra / type mismatch) | test payload verdict. List the limits you observed (max
last/{n}, max date range, earliest date) next to the values used inValidation/.
Don't change validators based on one observation without saying so: point out differences from the documented limits and let the maintainer decide.