Repository navigation
feat(cards): consolidate card velocity limit configuration - #1225
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 3 Skipped Deployments
|
Contributor
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
Contributor
|
This PR does not match any of the 3 configured review trigger rules. |
Contributor
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
DhruvPareek
added a commit
that referenced
this pull request
Oct 26, 2026
## Reason Card spending limits are changing from the strictest value across all scopes to inheritance by specificity. Document the policy so platforms can predict which configured cap will apply. ## Overview For each count or currency-specific amount cap and matching metric/window, use card scope first, platform scope second, and program scope last. At the selected scope the lower API or Lightspark-managed cap applies. An unset cap inherits; an explicit zero remains configured and blocks. Updates create/update/read card fields, platform defaults, and velocity-rule documentation. Amount and count inherit separately; distinct rolling durations remain independent. Provider-enforced account caps remain outside this Grid hierarchy. No request/response shape changes or new lifetime window. Stacked on #1225. Companion webdev PR implements this policy; the generated client update is kept separate from backend logic. ## Test Plan - `make build` — passed; regenerated both OpenAPI bundles. - `make lint` — passed (existing warnings only).
DhruvPareek
force-pushed
the
dp/card-velocity-rules-api
branch
from
October 26, 2026 21:26
68acaa3 to
305e38f
Compare
DhruvPareek
marked this pull request as ready for review
October 26, 2026 21:28
DhruvPareek
added a commit
that referenced
this pull request
Oct 26, 2026
Card spending limits are changing from the strictest value across all scopes to inheritance by specificity. Document the policy so platforms can predict which configured cap will apply. For each count or currency-specific amount cap and matching metric/window, use card scope first, platform scope second, and program scope last. At the selected scope the lower API or Lightspark-managed cap applies. An unset cap inherits; an explicit zero remains configured and blocks. Updates create/update/read card fields, platform defaults, and velocity-rule documentation. Amount and count inherit separately; distinct rolling durations remain independent. Provider-enforced account caps remain outside this Grid hierarchy. No request/response shape changes or new lifetime window. Stacked on #1225. Companion webdev PR implements this policy; the generated client update is kept separate from backend logic. - `make build` — passed; regenerated both OpenAPI bundles. - `make lint` — passed (existing warnings only).
DhruvPareek
force-pushed
the
dp/card-velocity-rules-api
branch
from
October 26, 2026 22:01
305e38f to
5151036
Compare
DhruvPareek
changed the title
DhruvPareek
added a commit
that referenced
this pull request
Oct 26, 2026
Card spending limits are changing from the strictest value across all scopes to inheritance by specificity. Document the policy so platforms can predict which configured cap will apply. For each count or currency-specific amount cap and matching metric/window, use card scope first, platform scope second, and program scope last. At the selected scope the lower API or Lightspark-managed cap applies. An unset cap inherits; an explicit zero remains configured and blocks. Updates create/update/read card fields, platform defaults, and velocity-rule documentation. Amount and count inherit separately; distinct rolling durations remain independent. Provider-enforced account caps remain outside this Grid hierarchy. No request/response shape changes or new lifetime window. Stacked on #1225. Companion webdev PR implements this policy; the generated client update is kept separate from backend logic. - `make build` — passed; regenerated both OpenAPI bundles. - `make lint` — passed (existing warnings only).
DhruvPareek
force-pushed
the
dp/card-velocity-rules-api
branch
from
October 26, 2026 22:54
5151036 to
fc8b95d
Compare
github-actions
Bot
added
the
breaking-change
Contributor
|
DhruvPareek
added a commit
that referenced
this pull request
Oct 26, 2026
Card spending limits are changing from the strictest value across all scopes to inheritance by specificity. Document the policy so platforms can predict which configured cap will apply. For each count or currency-specific amount cap and matching metric/window, use card scope first, platform scope second, and program scope last. At the selected scope the lower API or Lightspark-managed cap applies. An unset cap inherits; an explicit zero remains configured and blocks. Updates create/update/read card fields, platform defaults, and velocity-rule documentation. Amount and count inherit separately; distinct rolling durations remain independent. Provider-enforced account caps remain outside this Grid hierarchy. No request/response shape changes or new lifetime window. Stacked on #1225. Companion webdev PR implements this policy; the generated client update is kept separate from backend logic. - `make build` — passed; regenerated both OpenAPI bundles. - `make lint` — passed (existing warnings only).
DhruvPareek
force-pushed
the
dp/card-velocity-rules-api
branch
from
October 26, 2026 22:58
fc8b95d to
22cdafc
Compare
DhruvPareek
added a commit
that referenced
this pull request
Oct 26, 2026
Card spending limits are changing from the strictest value across all scopes to inheritance by specificity. Document the policy so platforms can predict which configured cap will apply. For each count or currency-specific amount cap and matching metric/window, use card scope first, platform scope second, and program scope last. At the selected scope the lower API or Lightspark-managed cap applies. An unset cap inherits; an explicit zero remains configured and blocks. Updates create/update/read card fields, platform defaults, and velocity-rule documentation. Amount and count inherit separately; distinct rolling durations remain independent. Provider-enforced account caps remain outside this Grid hierarchy. No request/response shape changes or new lifetime window. Stacked on #1225. Companion webdev PR implements this policy; the generated client update is kept separate from backend logic. - `make build` — passed; regenerated both OpenAPI bundles. - `make lint` — passed (existing warnings only).
DhruvPareek
force-pushed
the
dp/card-velocity-rules-api
branch
from
October 26, 2026 23:43
22cdafc to
7a52af6
Compare
benwgold
approved these changes
Oct 27, 2026
DhruvPareek
added a commit
that referenced
this pull request
Oct 27, 2026
Card spending limits are changing from the strictest value across all scopes to inheritance by specificity. Document the policy so platforms can predict which configured cap will apply. For each count or currency-specific amount cap and matching metric/window, use card scope first, platform scope second, and program scope last. At the selected scope the lower API or Lightspark-managed cap applies. An unset cap inherits; an explicit zero remains configured and blocks. Updates create/update/read card fields, platform defaults, and velocity-rule documentation. Amount and count inherit separately; distinct rolling durations remain independent. Provider-enforced account caps remain outside this Grid hierarchy. No request/response shape changes or new lifetime window. Stacked on #1225. Companion webdev PR implements this policy; the generated client update is kept separate from backend logic. - `make build` — passed; regenerated both OpenAPI bundles. - `make lint` — passed (existing warnings only).
DhruvPareek
added a commit
that referenced
this pull request
Oct 27, 2026
Card spending limits are changing from the strictest value across all scopes to inheritance by specificity. Document the policy so platforms can predict which configured cap will apply. For each count or currency-specific amount cap and matching metric/window, use card scope first, platform scope second, and program scope last. At the selected scope the lower API or Lightspark-managed cap applies. An unset cap inherits; an explicit zero remains configured and blocks. Updates create/update/read card fields, platform defaults, and velocity-rule documentation. Amount and count inherit separately; distinct rolling durations remain independent. Provider-enforced account caps remain outside this Grid hierarchy. No request/response shape changes or new lifetime window. Stacked on #1225. Companion webdev PR implements this policy; the generated client update is kept separate from backend logic. - `make build` — passed; regenerated both OpenAPI bundles. - `make lint` — passed (existing warnings only).
DhruvPareek
added a commit
that referenced
this pull request
Oct 27, 2026
Card spending limits are changing from the strictest value across all scopes to inheritance by specificity. Document the policy so platforms can predict which configured cap will apply. For each count or currency-specific amount cap and matching metric/window, use card scope first, platform scope second, and program scope last. At the selected scope the lower API or Lightspark-managed cap applies. An unset cap inherits; an explicit zero remains configured and blocks. Updates create/update/read card fields, platform defaults, and velocity-rule documentation. Amount and count inherit separately; distinct rolling durations remain independent. Provider-enforced account caps remain outside this Grid hierarchy. No request/response shape changes or new lifetime window. Stacked on #1225. Companion webdev PR implements this policy; the generated client update is kept separate from backend logic. - `make build` — passed; regenerated both OpenAPI bundles. - `make lint` — passed (existing warnings only).
7 tasks done
This branch was successfully deployed
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
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
Card velocity limits currently have separate configuration fields on card and platform resources. Make the velocity-rule collection the single API configuration surface, with consistent amount/count semantics and documentation.
Overview
Defines create, list, get, and delete at
/card-velocity-limitsand/card-velocity-limits/{id}. Omitting/nullcardIdconfigures per-card platform defaults; supplying it targets one owned card. Creation returns 201, while an existing target/metric/window/duration returns 409 CONFLICT with the unchanged rule's ID. Delete/recreate is explicit; inheritance governs the interval between requests and a failed replacement leaves deletion in effect.Removes
maxSpendPerTransaction,maxSpendPerDay, andmaxTransactionsPerDayfrom card creation/update, card responses, platformCardConfig, and agent card update requests. The surrounding card/config endpoints remain for their other operations. Replaces the three scalar-limit capability flags withsupportsVelocityLimits. Agent-wide budgets, merchant-category controls, risk ceilings, and provider-enforced constraints remain separate.All Grid-managed per-authorization, UTC calendar, and rolling amount/count controls use the rule API. Requests/responses have no currency field; amount caps use each card's minor units, including USD cents for USDB-funded USD cards. APPROVED includes $0 approvals; amount usage is holds less releases, while releases do not restore the approval count. Rules apply only where Grid decides authorizations. Platforms cannot access another platform's or Lightspark-managed rules.
Adds the Velocity Limits guide and navigation, updates issuance/wallet/status documentation, removes scalar-limit examples, and refreshes webhook samples. The top-level path follows
/card-disputes/{id}:/cards/velocity-limits/{id}fails Grid's ambiguity lint against existing/cards/{id}/reveal, tokenize, and PIN actions. Underlying rule model/ID names are retained.This is the API contract/documentation change. It does not migrate database settings or backend handlers. The backend must adopt the new route, canonical rule storage, and capability flag before this contract and its generated client are deployed. Generated artifacts are in webdev #39019, with #1226 inheritance documentation generated in webdev #39024. These generated PRs require the backend migration before merging; the separate regeneration #39178 has been consolidated into them. Card → platform → program inheritance is described here and refined by child #1226.
Test Plan
make buildandmake linton both API branches — passed, 0 errors (187 warnings, 740 infos).@mdx-js/mdx— passed.main(4f1963bf) and rebuilt both generated bundles to resolve conflicts, retaining the upstream agent card hand-over endpoint and SWIFT/UETR models. Removed the API/Lightspark lower-cap wording from the guide and endpoint description; enforcement is unchanged.