feat: add Stainless SDK config and misc cleanups

[pengying]

Grid API SDK Configuration

• Add .stainless/stainless.yml and workspace.json for SDK generation
• Add AllErrors schema to properly handle error types
• Replace Error schema references with GridError
• Fix phone number format in UltimateBeneficialOwner to include '+' prefix
• Update .redocly.lint-ignore.yaml with additional rule exceptions
• Fix internal_accounts schema reference path

[pengying]

• feat: add Stainless SDK config and misc cleanups #132 👈 (View in Graphite)
• feat: rename Error to GridError and add additionalProperties to error schemas #131
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Greptile Overview

Greptile Summary

This PR adds Stainless SDK generation configuration and performs several OpenAPI schema cleanups to prepare for automated SDK generation.

Key Changes:

• Added Stainless SDK configuration files (.stainless/stainless.yml and workspace.json) for TypeScript and Kotlin SDK generation
• Added GitHub Actions workflow to automatically build SDK previews on PRs and merge builds
• Introduced AllErrors schema as a union type of all error responses for better SDK error handling
• Fixed InternalAccount schema reference path from non-existent users/InternalAccount to correct customers/InternalAccount
• Updated phone number example in UltimateBeneficialOwner to include '+' prefix matching E.164 format
• Added explicit type: string to umaAddress field in CustomerCreateRequest
• Replaced generic Error schema with specific Error410 schema for customer deletion endpoint

Schema Improvements:
The AllErrors schema provides a discriminated union of all HTTP error types, which enables SDK generators like Stainless to create type-safe error handling. The Stainless config includes transformations to split this union by the code enum property, generating distinct error classes per error type.

Confidence Score: 5/5

• This PR is safe to merge with no identified issues
• All changes are configuration and documentation updates for SDK generation. The OpenAPI schema fixes are straightforward corrections (fixing broken references, adding missing type declarations, correcting examples). The Stainless configuration is comprehensive and properly structured. No runtime code changes or logic alterations that could introduce bugs.
• No files require special attention

Important Files Changed

Filename	Overview
.github/workflows/stainless-action.yml	Added GitHub Actions workflow for Stainless SDK generation on PR events
.stainless/stainless.yml	Added comprehensive Stainless SDK configuration for TypeScript and Kotlin targets
openapi/openapi.yaml	Added AllErrors schema with refs to specific error schemas
openapi/components/schemas/customers/UltimateBeneficialOwner.yaml	Fixed phone number example to include '+' prefix matching E.164 format
openapi/paths/internal-accounts/internal_accounts.yaml	Fixed schema reference from non-existent users/InternalAccount to customers/InternalAccount

Sequence Diagram

sequenceDiagram
    participant Dev as Developer
    participant GH as GitHub PR
    participant Workflow as Stainless Action
    participant Stainless as Stainless API
    participant SDK as Generated SDK

    Dev->>GH: Opens/Updates PR
    GH->>Workflow: Trigger (opened/synchronize/reopened)
    Workflow->>Workflow: Checkout repository
    Workflow->>Stainless: Upload OpenAPI spec (preview)
    Stainless->>Stainless: Validate OpenAPI spec
    Stainless->>Stainless: Generate TypeScript SDK
    Stainless->>Stainless: Generate Kotlin SDK
    Stainless->>GH: Post preview comment on PR
    
    Dev->>GH: Merges PR
    GH->>Workflow: Trigger (closed + merged)
    Workflow->>Workflow: Checkout repository
    Workflow->>Stainless: Upload OpenAPI spec (merge)
    Stainless->>SDK: Build and publish SDKs
    Stainless->>GH: Post merge status

Loading

[greptile-apps]

_{9 files reviewed, 3 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (1)

openapi.yaml
Inconsistent error schema name

This PR renames #/components/schemas/Error to #/components/schemas/GridError in the bundled specs (openapi.yaml / mintlify/openapi.yaml), but the modular spec still references error schemas under openapi/components/schemas/errors/Error*.yaml and also uses common/GridError.yaml for a 410 response (openapi/paths/customers/customers_{customerId}.yaml:172). Since GridError and Error400/Error401 etc are separate shapes, it’s easy for clients to end up with inconsistent error typing depending on endpoint/status. Please confirm the intended canonical error model and update the remaining path/components refs so all non-2xx responses consistently use the same error schema family.

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi.yaml
Line: 4444:4469

Comment:
**Inconsistent error schema name**

This PR renames `#/components/schemas/Error` to `#/components/schemas/GridError` in the bundled specs (`openapi.yaml` / `mintlify/openapi.yaml`), but the modular spec still references error schemas under `openapi/components/schemas/errors/Error*.yaml` and also uses `common/GridError.yaml` for a 410 response (`openapi/paths/customers/customers_{customerId}.yaml:172`). Since `GridError` and `Error400`/`Error401` etc are separate shapes, it’s easy for clients to end up with inconsistent error typing depending on endpoint/status. Please confirm the intended canonical error model and update the remaining path/components refs so all non-2xx responses consistently use the same error schema family.

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

[greptile-apps]

_{9 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (1)

openapi/paths/customers/customers_{customerId}.yaml
410 response schema mismatch

The 410 response now references ../../components/schemas/common/GridError.yaml, but the 401/404/500 responses in this same file still reference ../../components/schemas/errors/Error*.yaml. If 410 is meant to follow the standard error envelope used elsewhere, it should reference the appropriate errors/Error410.yaml schema; otherwise clients will have to special-case 410 to a different error shape than other error responses for this endpoint.

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi/paths/customers/customers_{customerId}.yaml
Line: 167:173

Comment:
**410 response schema mismatch**

The `410` response now references `../../components/schemas/common/GridError.yaml`, but the `401/404/500` responses in this same file still reference `../../components/schemas/errors/Error*.yaml`. If `410` is meant to follow the standard error envelope used elsewhere, it should reference the appropriate `errors/Error410.yaml` schema; otherwise clients will have to special-case `410` to a different error shape than other error responses for this endpoint.

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

[greptile-apps]

_{9 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

_{6 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (2)

mintlify/openapi.yaml
Missing type for property

umaAddress is defined with description/example but no type in the schema, which makes the property schema invalid/ambiguous for OpenAPI tooling and SDK generation. Add type: string (matching the example and intended semantics).

Prompt To Fix With AI

This is a comment left during a code review.
Path: mintlify/openapi.yaml
Line: 4358:4360

Comment:
**Missing `type` for property**

`umaAddress` is defined with `description`/`example` but no `type` in the schema, which makes the property schema invalid/ambiguous for OpenAPI tooling and SDK generation. Add `type: string` (matching the example and intended semantics).

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

---

openapi.yaml
Missing type for property

umaAddress is defined with description/example but no type. OpenAPI requires each property schema to be a valid schema object; without type this becomes ambiguous and can break validators/SDK generation. Add type: string for umaAddress (as done in the split schema).

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi.yaml
Line: 4369:4371

Comment:
**Missing `type` for property**

`umaAddress` is defined with `description`/`example` but no `type`. OpenAPI requires each property schema to be a valid schema object; without `type` this becomes ambiguous and can break validators/SDK generation. Add `type: string` for `umaAddress` (as done in the split schema).

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

[github-actions]

✱ Stainless preview builds

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

feat: add Stainless SDK config and misc cleanups

✅ grid-openapi studio · code

Your SDK built successfully.
generate ✅

⚠️ grid-typescript studio · code

There was a regression in your SDK.
generate ✅ → build ❗ → lint ❗ → test ✅

⚠️ grid-kotlin studio · code

There was a regression in your SDK.
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-02-05 23:55:30 UTC

[greptile-apps]

_{11 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[pengying]

Merge activity

• Feb 5, 11:49 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Feb 5, 11:49 PM UTC: @pengying merged this pull request with Graphite.