[platform-spending-caps]: add a platform per-transaction spending cap - #865
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
This stack of pull requests is managed by Graphite. Learn more about stacking. |
✱ Stainless preview builds for gridThis PR will update the cli go kotlin openapi php python ruby typescript ✅ grid-ruby studio · code
|
Greptile SummaryAdds an optional, nullable platform-wide per-transaction card spending cap to the platform configuration contract and documents that Grid enforces the lower of the platform and card-specific caps.
Confidence Score: 5/5The contract change appears safe to merge, with no concrete blocking or independently actionable non-blocking defect identified. The new field follows the established nullable int64 pattern, preserves omission-versus-null semantics in the contract, consistently distinguishes stored and effective card limits, and appears in both generated bundles.
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/config/PlatformConfig.yaml | Adds the nullable platform-level card cap to configuration responses with its scope and immediate-effect semantics. |
| openapi/components/schemas/config/PlatformConfigUpdateRequest.yaml | Adds consistent tri-state update semantics using the repository’s established nullable-int64 schema pattern. |
| openapi/components/schemas/cards/Card.yaml | Clarifies that the returned card field is the stored card-specific cap and not the lower effective limit. |
| openapi/paths/platform/config.yaml | Documents the new PATCH behavior and includes the cap in the request example. |
| openapi/paths/cards/cards.yaml | Updates card issuance documentation to explain interaction between card and platform caps. |
| openapi/paths/cards/cards_{id}.yaml | Updates card modification documentation while preserving existing set, clear, and closed-card constraints. |
| openapi.yaml | Generated root bundle is aligned with the modular OpenAPI source. |
| mintlify/openapi.yaml | Generated Mintlify contract is aligned with the modular OpenAPI source. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
P[Platform maxCardSpendPerTransaction] --> E{Both caps configured?}
C[Card maxSpendPerTransaction] --> E
E -->|Yes| L[Effective limit = lower value]
E -->|Platform only| P1[Effective limit = platform cap]
E -->|Card only| C1[Effective limit = card cap]
E -->|Neither| N[No Grid per-transaction cap]
G{Who decides authorization?} -->|Grid| E
G -->|Provider| U[Platform cap does not apply]
Reviews (1): Last reviewed commit: "feat(cards): add a platform per-transact..." | Re-trigger Greptile
b59d674 to
0d5bb9a
Compare
|
Merge activity
|

Reason
Platforms need one reversible control that caps every Grid-decided card transaction without destroying stricter per-card settings, while leaving room for additional card settings in the public contract.
Overview
Adds a nested
cardConfigsobject to platform config responses andPATCH /config. Its first setting,cardConfigs.maxSpendPerTransaction, is a platform-level cap: a positive int64 sets it, omission preserves it, andnullclears it. Grid enforces the lower of this cap and each card-specificmaxSpendPerTransaction; the contract states that the cap applies to existing and future cards while provider-decided card programs remain unaffected.Updates card create, update, and response documentation to distinguish the stored card-specific cap from the effective enforced limit. This PR defines the source OpenAPI contract only; generated Webdev artifacts and server implementation follow in separate Webdev PRs.
Test Plan
make buildmake lint— passed with the repository's existing warning set and no errorsgit diff --check