feat(internal-accounts): record the customer a platform rule-based account receives for

[ls-bolt]

This PR has been claimed. The active PR is now #1081.

Summary

Adds onBehalfOfCustomerId to internal accounts. A platform-owned rule-based account can now name the customer whose payments it receives, while the platform keeps owning the account.

• InternalAccountCreateRequest.onBehalfOfCustomerId (optional): accepted only when customerId is omitted. It must name a customer of the calling platform. The customer does not need to be verified. Several accounts can name the same customer.
• InternalAccount.onBehalfOfCustomerId: echoed on reads, and omitted for accounts that name no customer, including every customer-owned account.
• POST /internal-accounts:
  • new onBehalfOfCustomer request example
  • 400 now covers sending onBehalfOfCustomerId together with customerId
  • 404 now covers an onBehalfOfCustomerId that names no customer of the platform

Non-breaking: an optional request field and an optional response field.

Implementation

The server side, and the regenerated client that depends on this spec, is in lightsparkdev/webdev#34152. Merge this PR first.

Test plan

• make build rebundles openapi.yaml and mintlify/openapi.yaml.
• make lint-openapi: 0 errors, the same as main.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
Grid	🟢 Ready	View Preview	Sep 26, 2026, 12:28 AM

[vercel]

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

3 Skipped Deployments

Project	Deployment	Actions	Updated
grid-cards-demo	Ignored	Preview	Sep 26, 2026 12:28am UTC
grid-flow-builder	Ignored	Preview	Sep 26, 2026 12:28am UTC
grid-wallet-demo	Ignored	Preview	Sep 26, 2026 12:28am UTC

[ls-bolt]

@greptile review

[lightspark-bot]

• feat(internal-accounts): record the customer a platform rule-based account receives for #1080 👈 (View in Graphite)
• main

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

[greptile-apps]

Confidence Score: 4/5

[Critical risk] Adds a new field to the public API contract for internal accounts.

The PR should not merge until the response schema accepts the documented null value.

Findings

1.  Null response value is disallowed ▶

Fix with agent prompt

### Issue 1
openapi/components/schemas/customers/InternalAccount.yaml:36-38
For accounts that name no customer, including every customer-owned account, the description says this field is `null`. But `type: string` does not allow `null` in this OpenAPI 3.1 schema. A response containing the documented value will fail schema validation and may fail deserialization in generated clients. Declare the field as accepting both strings and null.

```suggestion
    type: [string, 'null']
    description: >-
      The customer whose payments this platform-owned account receives. Null
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR adds an optional customer attribution ID to platform-owned rule-based account creation and responses, plus a request example and error descriptions.

• The response schema does not permit the null value documented for accounts without an attributed customer.

_{Reviews (1) · Last reviewed commit: "feat(internal-accounts): record the cust..."}

[greptile-apps]

Null response value is disallowed
For accounts that name no customer, including every customer-owned account, the description says this field is null. But type: string does not allow null in this OpenAPI 3.1 schema. A response containing the documented value will fail schema validation and may fail deserialization in generated clients. Declare the field as accepting both strings and null.

Suggested change

	type: string
	description: >-
	The customer whose payments this platform-owned account receives. Null
	type: [string, 'null']
	description: >-
	The customer whose payments this platform-owned account receives. Null

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi/components/schemas/customers/InternalAccount.yaml
Line: 36-38

Comment:
**Null response value is disallowed**
For accounts that name no customer, including every customer-owned account, the description says this field is `null`. But `type: string` does not allow `null` in this OpenAPI 3.1 schema. A response containing the documented value will fail schema validation and may fail deserialization in generated clients. Declare the field as accepting both strings and null.

```suggestion
    type: [string, 'null']
    description: >-
      The customer whose payments this platform-owned account receives. Null
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[ls-bolt]

Right that the wording was wrong, but the value is never actually null: the server serializes with exclude_none, so an unset field is omitted. I fixed the description to say "Omitted" instead of widening the type (f119a55). The sibling label field follows the same convention, and the spec has no [string, 'null'] fields.

---

🤖 charged-neutron-69(#69) | Feedback

[greptile-apps]

That resolves the concern. An optional type: string property may be omitted, and the updated description now documents omission rather than null; with exclude_none serialization, the response matches the schema. The existing label convention further supports this approach, so no [string, 'null'] widening is needed.