feat(openapi): add CardTransaction to TransactionOneOf for the transaction list#622
Conversation
…ction list
Add CardTransaction as a third TransactionOneOf member with a CARD discriminator
so card transactions appear in GET /transactions and deserialize cleanly via the
discriminator. Add a type: CARD discriminator property to CardTransaction and
relax cardId / pullSummary / refundSummary / settlementSummary to optional so the
served card-transaction shape (the GET /transactions/{id} projection) validates.
Document on the list endpoint that card transactions are identified by type: CARD
and that this is how integrators discover a CardTransaction id in Sandbox.
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
This stack of pull requests is managed by Graphite. Learn more about stacking. |
|
✱ Stainless preview builds for gridThis PR will update the cli csharp go kotlin openapi php python ruby typescript ✅ grid-ruby studio · code
|
Greptile SummaryThis PR adds
Confidence Score: 4/5Safe to merge with a follow-up to document the status-filter incompatibility for card transactions. The
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/cards/CardTransaction.yaml | Added type: CARD discriminator property and promoted customerId/platformCustomerId to required; cardId, pullSummary, refundSummary, settlementSummary relaxed to optional. Schema description inaccurately says "extends the Transaction model" (not an allOf inheritance). |
| openapi/components/schemas/transactions/TransactionOneOf.yaml | Adds CardTransaction as a third oneOf member with CARD discriminator mapping. Straightforward and correct. |
| openapi/paths/transactions/transactions.yaml | Added documentation that card transactions appear in the list via type: CARD. The status query parameter still only accepts TransactionStatus values (payment-style), making it impossible to server-side filter card transactions by their own status values (AUTHORIZED, SETTLED, etc.) — this limitation is undocumented. |
| openapi.yaml | Generated bundle reflecting the spec changes — not edited directly per repo convention. |
| mintlify/openapi.yaml | Mintlify copy of the generated bundle — mirrors openapi.yaml changes. |
Sequence Diagram
%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
participant Client
participant GridAPI as GET /transactions
participant SimAuth as POST /simulate/card-auth
participant SimClear as POST /simulate/card-clearing
Client->>SimAuth: Simulate card authorization
SimAuth-->>Client: 200 OK (cardTransactionId in webhook)
Client->>GridAPI: GET /transactions
GridAPI-->>Client: "200 [{type: INCOMING,...},{type: CARD, id: CardTransaction:..., status: AUTHORIZED,...}]"
Note over Client,GridAPI: Client filters on type === CARD to find cardTransactionId
Client->>SimClear: "POST /simulate/card-clearing { cardTransactionId }"
SimClear-->>Client: 200 OK (status to SETTLED)
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
participant Client
participant GridAPI as GET /transactions
participant SimAuth as POST /simulate/card-auth
participant SimClear as POST /simulate/card-clearing
Client->>SimAuth: Simulate card authorization
SimAuth-->>Client: 200 OK (cardTransactionId in webhook)
Client->>GridAPI: GET /transactions
GridAPI-->>Client: "200 [{type: INCOMING,...},{type: CARD, id: CardTransaction:..., status: AUTHORIZED,...}]"
Note over Client,GridAPI: Client filters on type === CARD to find cardTransactionId
Client->>SimClear: "POST /simulate/card-clearing { cardTransactionId }"
SimClear-->>Client: 200 OK (status to SETTLED)
Reviews (2): Last reviewed commit: "address Greptile review: add customerId/..." | Re-trigger Greptile
…nsaction Mirror the base Transaction model so listed card transactions are attributable to a customer and consistent with the GET /transactions customerId / platformCustomerId filters. Co-Authored-By: greptile-apps[bot] <greptile-apps[bot]@users.noreply.github.com>

Summary (draft / PoC — PR 2 of 2 spec change)
Adds
CardTransactionas a thirdTransactionOneOfmember with aCARDdiscriminator so card transactions appear inGET /transactionsand deserialize cleanly via the discriminator. This is the canonical spec change behind the Lightspark webdev SDK regen + sparkcore handler change (the companion PR) that unblocks the documented Grid sandbox card loop (simulate auth → list → simulate clearing → simulate return): integrators discover thecardTransactionIdfrom the public transaction list instead of needing the internal dashboard.Changes
TransactionOneOf: addCardTransaction+CARDdiscriminator mapping.CardTransaction: add atype: CARDdiscriminator property; relaxcardId,pullSummary,refundSummary,settlementSummaryto optional so the served card-transaction shape (theGET /transactions/{id}projection) validates and the list deserializes cleanly even for card transactions without a resolved card.GET /transactions: document that card transactions are identified bytype: CARDand that this is how integrators discover aCardTransactionid in Sandbox.The bundled
openapi.yaml/mintlify/openapi.yamlcarry only this change (the redocly rebundle reorders unrelated schemas, so the diff is scoped to the actual change; runmake buildon merge to fully re-normalize).Known limitations (PoC)
processorTransactionToken; the schema exposesissuerTransactionToken. SDK deserialization still succeeds (the loop works viaid), but the token isn't surfaced under the typed field — flagged for a follow-up rename.GET /transactions?type=CARDis not yet a valid filter (TransactionTypeisINCOMING/OUTGOING); clients filter client-side ontype: CARD. Follow-up.🤖 arcing-fulcrum(#1) | Feedback
Original PR: #621