Expose transaction receipt fields

[bsiaotickchong]

Summary

• Add optional transactionHash to reconciliationInstructions for destination-side crypto settlement receipt data.
• Make reference optional so reconciliation instructions can contain only a transaction hash when no payment reference exists.
• Add optional fees to incoming transactions, denominated in the receiving currency's smallest unit.
• Rebuild bundled OpenAPI specs for openapi.yaml and mintlify/openapi.yaml.

Testing

• make build
• make lint

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
grid-flow-builder	Ready	Preview, Comment	May 26, 2026 11:57pm

[github-actions]

✱ Stainless preview builds for grid

This PR will update the grid SDKs with the following commit messages.

cli

feat: Expose transaction receipt fields

csharp

feat: Expose transaction receipt fields

go

feat: Expose transaction receipt fields

kotlin

feat: Expose transaction receipt fields

openapi

feat: Expose transaction receipt fields

php

feat: Expose transaction receipt fields

python

feat: Expose transaction receipt fields

ruby

feat: Expose transaction receipt fields

typescript

feat: Expose transaction receipt fields

Edit this comment to update them. They will appear in their respective SDK's changelogs.

✅ grid-openapi studio · code · diff

Your SDK build had at least one "error" diagnostic, but this did not represent a regression.
generate ❗

✅ grid-ruby studio · code · diff

Your SDK build had at least one "error" diagnostic, but this did not represent a regression.
generate ❗ → build ✅ (prev: build ⏭️) → lint ❗ → test ✅

✅ grid-go studio · code · diff

Your SDK build had at least one "error" diagnostic, but this did not represent a regression.
generate ❗ → build ✅ (prev: build ⏭️) → lint ❗ → test ❗

go get github.com/stainless-sdks/grid-go@5de7348ccbbf3873604d8f24b0e75925e6cc8bbf

⚠️ grid-typescript studio · code · diff

Your SDK build had a failure in the build CI job, which is a regression from the base state.
generate ❗ → build ❗ (prev: build ⏭️) → lint ❗ (prev: lint ⏭️) → test ❗

✅ grid-kotlin studio · code · diff

Your SDK build had at least one "error" diagnostic, but this did not represent a regression.
generate ❗ → build ✅ (prev: build ⏭️) → lint ✅ (prev: lint ⏭️) → test ❗

✅ grid-python studio · code · diff

Your SDK build had at least one "error" diagnostic, but this did not represent a regression.
generate ❗ → build ✅ (prev: build ⏭️) → lint ✅ (prev: lint ⏭️) → test ✅

pip install https://pkg.stainless.com/s/grid-python/855c4498c77fa699fe0463f458ca61278d091fd4/grid-0.0.1-py3-none-any.whl

⚠️ grid-csharp studio · code · diff

Your SDK build had a failure in the build CI job, which is a regression from the base state.
generate ❗ → build ❗ (prev: build ⏭️) → lint ❗ (prev: lint ⏭️) → test ❗

✅ grid-php studio · code · diff

Your SDK build had at least one "error" diagnostic, but this did not represent a regression.
generate ❗ → lint ❗ → test ✅

✅ grid-cli studio · code · diff

Your SDK build had at least one "error" diagnostic, but this did not represent a regression.
generate ❗ → build ❗ → lint ❗ → test ❗

---

This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push.
If you push custom code to the preview branch, re-run this workflow to update the comment.
Last updated: 2026-05-27 00:02:18 UTC

[greptile-apps]

Greptile Summary

This PR extends the IncomingTransaction and ReconciliationInstructions schemas to surface crypto receipt data: transactionHash is added as an optional field to ReconciliationInstructions, reference is made optional (previously required), and an optional fees field (int64, smallest currency unit) is added to IncomingTransaction. Both bundled specs (openapi.yaml, mintlify/openapi.yaml) are rebuilt accordingly.

• IncomingTransaction.fees — clean addition; integer type, minimum: 0, and a clear description.
• ReconciliationInstructions.transactionHash — new optional crypto hash field; no format/pattern constraint, which is acceptable for a cross-chain field.
• ReconciliationInstructions.reference — made optional, but the field description still says "must be included with the payment", and no schema constraint prevents an empty {} object when both fields are absent.

Confidence Score: 3/5

Safe to merge once the empty-object gap in ReconciliationInstructions is addressed; the fees addition is clean.

Making reference optional without adding any constraint that at least one of reference or transactionHash must be present means a client could receive a reconciliationInstructions: {} object that carries no matching data at all. That is a logical hole in the schema contract that quietly allows bad data to pass validation. The fees addition and both bundle rebuilds look correct.

openapi/components/schemas/common/ReconciliationInstructions.yaml — the optionality change and stale description both need attention before merging.

Important Files Changed

Filename	Overview
openapi/components/schemas/common/ReconciliationInstructions.yaml	Makes reference optional and adds transactionHash; stale "must be included" description and no constraint preventing a fully-empty object.
openapi/components/schemas/transactions/IncomingTransaction.yaml	Adds optional fees field (int64, minimum 0) to incoming transactions; straightforward and well-formed.
openapi.yaml	Generated bundle reflecting the source schema changes; no issues beyond those already flagged in the source files.
mintlify/openapi.yaml	Mintlify-targeted generated bundle; identical changes to openapi.yaml, no independent issues.

Sequence Diagram

sequenceDiagram
    participant Client
    participant GridAPI

    Client->>GridAPI: "GET /transactions/{id}"
    GridAPI-->>Client: IncomingTransaction response
    note over Client,GridAPI: New optional fields in response
    note right of GridAPI: fees (int64, min 0)<br/>reconciliationInstructions.transactionHash
    note right of GridAPI: reconciliationInstructions.reference<br/>is now optional (was required)
    Client->>Client: Handle reconciliationInstructions
    alt reference present
        Client->>Client: Use reference for payment matching
    else transactionHash present
        Client->>Client: Use transactionHash for crypto receipt
    else neither present (now schema-valid)
        Client->>Client: Empty object — no matching data
    end

Loading

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
openapi/components/schemas/common/ReconciliationInstructions.yaml:3-8
**Stale "must be included" wording after making `reference` optional**

The `reference` field description still reads "must be included with the payment", but the `required` constraint was just removed. Any API consumer reading this description will think the field is mandatory when the schema now treats it as optional — the two are in direct conflict.

### Issue 2 of 2
openapi/components/schemas/common/ReconciliationInstructions.yaml:1-13
**Schema now accepts a fully-empty `ReconciliationInstructions` object**

With both `reference` and `transactionHash` optional, the object `{}` is valid per the schema. The PR description states the intent is to allow a transaction hash *when no payment reference exists*, implying at least one field should always be present. A `minProperties: 1` constraint (or an `anyOf` / `oneOf` requiring at least one of the two fields) would close the gap and prevent a semantically meaningless empty object from passing validation.

_{Reviews (1): Last reviewed commit: "feat(transactions): expose receipt recon..." | Re-trigger Greptile}

[greptile-apps]

Stale "must be included" wording after making reference optional

The reference field description still reads "must be included with the payment", but the required constraint was just removed. Any API consumer reading this description will think the field is mandatory when the schema now treats it as optional — the two are in direct conflict.

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi/components/schemas/common/ReconciliationInstructions.yaml
Line: 3-8

Comment:
**Stale "must be included" wording after making `reference` optional**

The `reference` field description still reads "must be included with the payment", but the `required` constraint was just removed. Any API consumer reading this description will think the field is mandatory when the schema now treats it as optional — the two are in direct conflict.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Schema now accepts a fully-empty ReconciliationInstructions object

With both reference and transactionHash optional, the object {} is valid per the schema. The PR description states the intent is to allow a transaction hash when no payment reference exists, implying at least one field should always be present. A minProperties: 1 constraint (or an anyOf / oneOf requiring at least one of the two fields) would close the gap and prevent a semantically meaningless empty object from passing validation.

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi/components/schemas/common/ReconciliationInstructions.yaml
Line: 1-13

Comment:
**Schema now accepts a fully-empty `ReconciliationInstructions` object**

With both `reference` and `transactionHash` optional, the object `{}` is valid per the schema. The PR description states the intent is to allow a transaction hash *when no payment reference exists*, implying at least one field should always be present. A `minProperties: 1` constraint (or an `anyOf` / `oneOf` requiring at least one of the two fields) would close the gap and prevent a semantically meaningless empty object from passing validation.

How can I resolve this? If you propose a fix, please make it concise.