fix: separating create customer from customer response schemas by pengying · Pull Request #142 · lightsparkdev/grid-api

pengying · 2026-01-31T00:28:33Z

TL;DR

Refactored customer schema definitions to use a consistent approach for both creation and update operations.

What changed?

Created new schema definitions for customer creation requests:
- CustomerCreateRequest as a base schema
- IndividualCustomerCreateRequest and BusinessCustomerCreateRequest extending the base schema
- CustomerCreateRequestOneOf to handle the oneOf relationship between customer types
Replaced the separate update schemas (IndividualCustomerUpdate and BusinessCustomerUpdate) with the same creation request schemas
Updated API endpoints to reference the new schema definitions:
- Changed POST /customers to use CustomerCreateRequestOneOf
- Changed PATCH /customers/{customerId} to use CustomerCreateRequestOneOf

pengying · 2026-01-31T00:28:54Z

fix: separating create customer from customer response schemas #142 👈 (View in Graphite)
main

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

greptile-apps · 2026-01-31T00:32:38Z

Greptile Overview

Greptile Summary

Refactored customer schema architecture to separate create and update request schemas with consistent structure.

Created new CustomerCreateRequest base schema with required platformCustomerId field
Created IndividualCustomerCreateRequest and BusinessCustomerCreateRequest extending the base
Created CustomerUpdateRequest base schema without required platformCustomerId for partial updates
Introduced shared field schemas (BusinessCustomerFields, IndividualCustomerFields) for code reuse
Split BusinessInfo (requires legalName) and BusinessInfoUpdate (no required fields) to enforce validation rules appropriately
Updated POST /customers to use CustomerCreateRequestOneOf and PATCH /customers/{customerId} to use CustomerUpdateRequestOneOf
Removed deprecated schemas (BusinessCustomerUpdate, IndividualCustomerUpdate)

The refactoring maintains backward compatibility for the PATCH endpoint by keeping fields optional for partial updates, while enforcing stricter validation for POST requests.

Confidence Score: 4/5

Safe to merge after fixing syntax issues in CustomerCreateRequest.yaml
The refactoring is well-structured and maintains API compatibility by keeping separate schemas for create vs update operations. The only issues are minor syntax problems (missing type declaration and duplicate text) that need to be fixed before merging.
openapi/components/schemas/customers/CustomerCreateRequest.yaml requires fixes for missing type declaration and duplicate text

Important Files Changed

Filename	Overview
openapi/components/schemas/customers/CustomerCreateRequest.yaml	new base schema for customer creation with missing type declaration and duplicate text
openapi/components/schemas/customers/CustomerCreateRequestOneOf.yaml	simple oneOf wrapper for create requests, properly configured
openapi/components/schemas/customers/BusinessCustomerCreateRequest.yaml	correctly extends base create request with business fields requiring legalName
openapi/components/schemas/customers/CustomerUpdateRequest.yaml	base schema for updates without platformCustomerId requirement
openapi/components/schemas/customers/BusinessInfo.yaml	business info schema requiring legalName for creation
openapi/components/schemas/customers/BusinessInfoUpdate.yaml	business info schema without required fields for partial updates

Sequence Diagram

sequenceDiagram
    participant Client
    participant API as Grid API
    participant ValidationLayer as Schema Validation
    participant Database

    Note over Client,Database: Customer Creation Flow

    Client->>API: POST /customers
    Note right of Client: CustomerCreateRequestOneOf<br/>(requires platformCustomerId)
    API->>ValidationLayer: Validate request schema
    ValidationLayer->>ValidationLayer: Check customerType (INDIVIDUAL/BUSINESS)
    ValidationLayer->>ValidationLayer: Validate required fields<br/>(platformCustomerId, customerType)
    alt Business Customer
        ValidationLayer->>ValidationLayer: Validate BusinessInfo<br/>(legalName required)
    else Individual Customer
        ValidationLayer->>ValidationLayer: Validate IndividualCustomerFields
    end
    ValidationLayer->>API: Schema valid
    API->>Database: Create customer record
    Database->>API: Customer created
    API->>Client: 201 Created (Customer object)

    Note over Client,Database: Customer Update Flow

    Client->>API: PATCH /customers/{customerId}
    Note right of Client: CustomerUpdateRequestOneOf<br/>(platformCustomerId optional)
    API->>ValidationLayer: Validate request schema
    ValidationLayer->>ValidationLayer: Check customerType (INDIVIDUAL/BUSINESS)
    ValidationLayer->>ValidationLayer: Validate optional fields<br/>(partial update allowed)
    alt Business Customer Update
        ValidationLayer->>ValidationLayer: Validate BusinessInfoUpdate<br/>(no required fields)
    else Individual Customer Update
        ValidationLayer->>ValidationLayer: Validate IndividualCustomerFields
    end
    ValidationLayer->>API: Schema valid
    API->>Database: Update customer record
    Database->>API: Customer updated
    API->>Client: 200 OK (Updated Customer object)

greptile-apps

_{4 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

openapi/components/schemas/customers/BusinessCustomerCreateRequest.yaml

openapi/components/schemas/customers/CustomerCreateRequest.yaml

greptile-apps

_{3 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

openapi/components/schemas/customers/CustomerCreateRequest.yaml

greptile-apps

_{7 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

openapi/components/schemas/customers/CustomerCreateRequest.yaml

openapi/components/schemas/customers/IndividualCustomerFields.yaml

gcamata · 2026-02-02T02:54:04Z

openapi/components/schemas/customers/BusinessInfoUpdate.yaml

should we just have the one BusinessInfo.yaml (with legalName required)?

It was originally structured that way. The issue is that if you're patching a business, it's annoying to always include business legalName in every request.

I restructured it so legalName is required on create and in the response.

but optional in patch

greptile-apps

_{7 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

openapi/components/schemas/customers/CustomerCreateRequest.yaml

greptile-apps · 2026-02-02T18:59:39Z

openapi/components/schemas/customers/CustomerCreateRequest.yaml

+  umaAddress:
+    description: >-
+      Optional UMA address identifier. If not provided during customer creation, one will be generated by the system.
+      If provided during customer update, the UMA address will be updated to the provided value. This is an optional identifier to route payments to the customer.
+      This is an optional identifier to route payments to the customer.


duplicated sentence - "This is an optional identifier to route payments to the customer." appears twice

Suggested change

umaAddress:

description: >-

Optional UMA address identifier. If not provided during customer creation, one will be generated by the system.

If provided during customer update, the UMA address will be updated to the provided value. This is an optional identifier to route payments to the customer.

This is an optional identifier to route payments to the customer.

umaAddress:

type: string

description: >-

Optional UMA address identifier. If not provided during customer creation, one will be generated by the system.

If provided during customer update, the UMA address will be updated to the provided value. This is an optional identifier to route payments to the customer.

example: $john.doe@uma.domain.com

Prompt To Fix With AI

This is a comment left during a code review. Path: openapi/components/schemas/customers/CustomerCreateRequest.yaml Line: 12:16 Comment: duplicated sentence - "This is an optional identifier to route payments to the customer." appears twice ```suggestion umaAddress: type: string description: >- Optional UMA address identifier. If not provided during customer creation, one will be generated by the system. If provided during customer update, the UMA address will be updated to the provided value. This is an optional identifier to route payments to the customer. example: $john.doe@uma.domain.com ``` How can I resolve this? If you propose a fix, please make it concise.

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>

greptile-apps

_{5 files reviewed, 3 comments}

_{Edit Code Review Agent Settings | Greptile}

openapi/components/schemas/customers/CustomerCreateRequest.yaml

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>

greptile-apps

_{6 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-02T21:22:43Z

openapi/components/schemas/customers/CustomerCreateRequest.yaml

+  umaAddress:
+    description: >-
+      Optional UMA address identifier. If not provided during customer creation, one will be generated by the system.
+      If provided during customer update, the UMA address will be updated to the provided value. This is an optional identifier to route payments to the customer.
+      This is an optional identifier to route payments to the customer.


missing type: string for umaAddress field

Suggested change

umaAddress:

description: >-

Optional UMA address identifier. If not provided during customer creation, one will be generated by the system.

If provided during customer update, the UMA address will be updated to the provided value. This is an optional identifier to route payments to the customer.

This is an optional identifier to route payments to the customer.

umaAddress:

type: string

description: >-

Optional UMA address identifier. If not provided during customer creation, one will be generated by the system.

If provided during customer update, the UMA address will be updated to the provided value. This is an optional identifier to route payments to the customer.

example: $john.doe@uma.domain.com

Prompt To Fix With AI

This is a comment left during a code review. Path: openapi/components/schemas/customers/CustomerCreateRequest.yaml Line: 12:16 Comment: missing `type: string` for `umaAddress` field ```suggestion umaAddress: type: string description: >- Optional UMA address identifier. If not provided during customer creation, one will be generated by the system. If provided during customer update, the UMA address will be updated to the provided value. This is an optional identifier to route payments to the customer. example: $john.doe@uma.domain.com ``` How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-02T21:22:44Z

openapi/components/schemas/customers/CustomerCreateRequest.yaml

+      If provided during customer update, the UMA address will be updated to the provided value. This is an optional identifier to route payments to the customer.
+      This is an optional identifier to route payments to the customer.


duplicated text - "This is an optional identifier to route payments to the customer." appears twice

Suggested change

If provided during customer update, the UMA address will be updated to the provided value. This is an optional identifier to route payments to the customer.

This is an optional identifier to route payments to the customer.

If provided during customer update, the UMA address will be updated to the provided value. This is an optional identifier to route payments to the customer.

example: $john.doe@uma.domain.com

Prompt To Fix With AI

This is a comment left during a code review. Path: openapi/components/schemas/customers/CustomerCreateRequest.yaml Line: 15:16 Comment: duplicated text - "This is an optional identifier to route payments to the customer." appears twice ```suggestion If provided during customer update, the UMA address will be updated to the provided value. This is an optional identifier to route payments to the customer. example: $john.doe@uma.domain.com ``` How can I resolve this? If you propose a fix, please make it concise.

pengying marked this pull request as ready for review January 31, 2026 00:29

greptile-apps bot reviewed Jan 31, 2026

View reviewed changes

openapi/components/schemas/customers/BusinessCustomerCreateRequest.yaml Outdated Show resolved Hide resolved

openapi/components/schemas/customers/CustomerCreateRequest.yaml Show resolved Hide resolved

pengying force-pushed the 01-30-fix_separating_create_customer_from_customer_response_schemas branch from 00a920e to 4970949 Compare January 31, 2026 01:05

greptile-apps bot reviewed Jan 31, 2026

View reviewed changes

openapi/components/schemas/customers/CustomerCreateRequest.yaml Show resolved Hide resolved

openapi/components/schemas/customers/CustomerCreateRequest.yaml Show resolved Hide resolved

pengying force-pushed the 01-30-fix_separating_create_customer_from_customer_response_schemas branch from e93abea to f8c05b0 Compare January 31, 2026 04:11

greptile-apps bot reviewed Jan 31, 2026

View reviewed changes

openapi/components/schemas/customers/CustomerCreateRequest.yaml Show resolved Hide resolved

pengying force-pushed the 01-30-fix_separating_create_customer_from_customer_response_schemas branch from f8c05b0 to 51732f6 Compare January 31, 2026 04:18

gcamata reviewed Feb 2, 2026

View reviewed changes

openapi/components/schemas/customers/IndividualCustomerFields.yaml Show resolved Hide resolved

gcamata reviewed Feb 2, 2026

View reviewed changes

fix: separating create customer from customer response schemas

96dadbd

pengying force-pushed the 01-30-fix_separating_create_customer_from_customer_response_schemas branch from 51732f6 to 96dadbd Compare February 2, 2026 18:55

gcamata approved these changes Feb 2, 2026

View reviewed changes

greptile-apps bot reviewed Feb 2, 2026

View reviewed changes

Update openapi/components/schemas/customers/CustomerCreateRequest.yaml

8984f56

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>

greptile-apps bot reviewed Feb 2, 2026

View reviewed changes

openapi/components/schemas/customers/CustomerCreateRequest.yaml Outdated Show resolved Hide resolved

openapi/components/schemas/customers/CustomerCreateRequest.yaml Show resolved Hide resolved

openapi/components/schemas/customers/CustomerCreateRequest.yaml Show resolved Hide resolved

Update openapi/components/schemas/customers/CustomerCreateRequest.yaml

18173fa

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>

pengying enabled auto-merge (squash) February 2, 2026 21:19

greptile-apps bot reviewed Feb 2, 2026

View reviewed changes

pengying merged commit dde72cc into main Feb 2, 2026
8 of 13 checks passed

pengying deleted the 01-30-fix_separating_create_customer_from_customer_response_schemas branch February 2, 2026 23:18

		If provided during customer update, the UMA address will be updated to the provided value. This is an optional identifier to route payments to the customer.
		This is an optional identifier to route payments to the customer.

Conversation

pengying commented Jan 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

TL;DR

What changed?

Uh oh!

pengying commented Jan 31, 2026

Uh oh!

greptile-apps bot commented Jan 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Overview

Greptile Summary

Confidence Score: 4/5

Important Files Changed

Sequence Diagram

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

gcamata Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

pengying Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

pengying Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

greptile-apps bot Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

pengying commented Jan 31, 2026 •

edited

Loading

greptile-apps bot commented Jan 31, 2026 •

edited

Loading