feat(customer): add singular customer key on GET /v1/customer/:id#292
Merged
Conversation
The 200 response for \`GET /v1/customer/:id\` historically wrapped the single customer object under a plural \`customers\` key — a wart from before the codebase standardized on singular-for-single-row across the other 15 entities (\`worker\`, \`billingtype\`, \`job\`, ...). SDK clients generating typed accessors had to special-case Customer against every other entity. Surface the singular \`customer\` key in the same response, alongside the existing \`customers\` key. Existing clients reading \`customers\` keep working unchanged; new code can use \`customer\` and match the rest of the API. The pluralized key stays in the response for backward compat — a future major version can drop it; until then the cost is one extra JSON-payload reference (no payload size increase since both keys reference the same object). 761 tests still pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CryptoJones
added a commit
that referenced
this pull request
May 19, 2026
The OpenAPI spec declared the 200 body as a bare Customer
(`$ref: '#/components/schemas/Customer'`). The controller actually
wraps the row in a `{message, customer, customers}` envelope — the
dual `customer` (singular) + `customers` (plural, backward-compat
wart from before #292) key is documented in customercontroller.js's
findAndRespond.
SDK code-gen (openapi-typescript, quicktype, etc.) reading the
spec built clients expecting the bare row, then failed to find the
fields at runtime because they live one level deeper inside the
envelope.
Fix the spec to describe the actual envelope shape:
{
message: string,
customer: Customer,
customers: Customer
}
Also document the 404 response that the controller emits when the
row is missing — was previously not in the spec, so SDK clients
couldn't model that branch either.
Pin both with a test in tests/api/openapi.test.js.
Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The 200 response for
GET /v1/customer/:idhistorically wrapped the single customer object under a pluralcustomerskey — a wart from before the codebase standardized on singular-for-single-row across the other 15 entities (worker,billingtype,job, ...). SDK clients generating typed accessors had to special-case Customer against every other entity.Surface the singular
customerkey in the same response, alongside the existingcustomerskey. Existing clients readingcustomerskeep working unchanged; new code can usecustomerand match the rest of the API.Backward compatibility
customersstays in the response for now — a future major version can drop it.Test plan
npm run lint && npm test— 761 passing.Proudly Made in Nebraska. Go Big Red! 🌽 https://xkcd.com/2347/