feat(cards): add a platform per-transaction spending cap - #865
Open
DhruvPareek wants to merge 1 commit into
Open
feat(cards): add a platform per-transaction spending cap#865DhruvPareek wants to merge 1 commit into
DhruvPareek wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
Contributor
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
Contributor
✱ Stainless preview builds for gridThis PR will update the cli go kotlin openapi php python ruby typescript Edit this comment to update them. They will appear in their respective SDK's changelogs. ✅ grid-typescript studio · code · diff
✅ grid-openapi studio · code · diff
✅ grid-ruby studio · code · diff
✅ grid-go studio · code · diff
✅ grid-kotlin studio · code · diff
✅ grid-python studio · code · diff
✅ grid-php studio · code · diff
✅ grid-cli studio · code · diff
This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push. |
DhruvPareek
marked this pull request as ready for review
August 26, 2026 00:01
Contributor
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
DhruvPareek
force-pushed
the
dp/platform-card-spend-cap-api
branch
from
August 26, 2026 17:31
b59d674 to
0d5bb9a
Compare
github-actions
Bot
added
the
breaking-change
Contributor
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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