Repository navigation
docs(cards): describe scope-based spending limit inheritance - #1226
Draft
DhruvPareek wants to merge 1 commit into
Draft
DhruvPareek 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. 3 Skipped Deployments
|
Contributor
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
DhruvPareek
force-pushed
the
dp/card-velocity-rules-api
branch
from
October 26, 2026 21:26
68acaa3 to
305e38f
Compare
DhruvPareek
force-pushed
the
dp/card-limit-inheritance-docs
branch
from
October 26, 2026 21:26
d176bef to
7ae3617
Compare
DhruvPareek
force-pushed
the
dp/card-velocity-rules-api
branch
from
October 26, 2026 22:01
305e38f to
5151036
Compare
DhruvPareek
force-pushed
the
dp/card-limit-inheritance-docs
branch
2 times, most recently
from
October 26, 2026 22:54
5106f85 to
b9b4db5
Compare
DhruvPareek
force-pushed
the
dp/card-velocity-rules-api
branch
2 times, most recently
from
October 26, 2026 22:58
fc8b95d to
22cdafc
Compare
DhruvPareek
force-pushed
the
dp/card-limit-inheritance-docs
branch
2 times, most recently
from
October 26, 2026 23:43
f706502 to
ec14dbb
Compare
DhruvPareek
force-pushed
the
dp/card-velocity-rules-api
branch
from
October 26, 2026 23:43
22cdafc to
7a52af6
Compare
DhruvPareek
marked this pull request as ready for review
October 27, 2026 00:29
Contributor
 [Low impact] This documentation-only PR appears safe to merge. SummaryClarifies how card spending limits inherit without changing routes, fields, or enforcement.
No actionable issues found. Reviews (1) · Last reviewed commit: "docs(cards): describe scope-based spendi..." · Reviewed by Greptile |
benwgold
previously approved these changes
Oct 27, 2026
DhruvPareek
changed the base branch from
dp/card-velocity-rules-api
to
graphite-base/1226
October 27, 2026 16:43
DhruvPareek
added a commit
that referenced
this pull request
Oct 27, 2026
## 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-limits` and `/card-velocity-limits/{id}`. Omitting/null `cardId` configures 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`, and `maxTransactionsPerDay` from card creation/update, card responses, platform `CardConfig`, and agent card update requests. The surrounding card/config endpoints remain for their other operations. Replaces the three scalar-limit capability flags with `supportsVelocityLimits`. 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](lightsparkdev/webdev#39019), with #1226 inheritance documentation generated in [webdev #39024](lightsparkdev/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 build` and `make lint` on both API branches — passed, 0 errors (187 warnings, 740 infos).
- Parsed the new guide and all three edited snippets with `@mdx-js/mdx` — passed.
- Validated guide request/response examples and updated issuance examples against the bundled OpenAPI schema with AJV — passed.
- Structural assertions confirmed that only the three legacy limit properties were removed from each existing card/config model; unrelated properties, agent spending-policy shapes, and existing non-velocity routes are preserved.
- Searched source specs and card guides for the removed scalar fields, capability flags, and old route names — no remaining references.
- Restacked on current `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.
DhruvPareek
force-pushed
the
graphite-base/1226
branch
from
October 27, 2026 16:43
7a52af6 to
64bc49a
Compare
DhruvPareek
force-pushed
the
dp/card-limit-inheritance-docs
branch
from
October 27, 2026 16:43
ec14dbb to
3738b00
Compare
graphite-app
Bot
dismissed
benwgold’s stale review
October 27, 2026 16:44
The base branch was changed.
Contributor
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
DhruvPareek
force-pushed
the
dp/card-limit-inheritance-docs
branch
from
October 27, 2026 16:44
3738b00 to
caccef4
Compare
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-limit-inheritance-docs
branch
from
October 27, 2026 18:33
caccef4 to
23024b6
Compare
DhruvPareek
marked this pull request as draft
October 27, 2026 19:15
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
Make amount/count inheritance and deletion fallback explicit when a rule leaves one cap unset.
Overview
Clarifies that amount and count inherit independently from the next configured scope. Deleting the last cap at a scope restores its broader default until a replacement is created; a failed replacement leaves inheritance in effect.
#1225 has merged the consolidated configuration contract. This documentation-only child now targets
main, retaining #1212's real-time authorization definitions. It changes rule descriptions without changing endpoint or model shapes. The matching generated documentation is in webdev #39024, after the consolidated client in #39019; backend consolidation onto stored rules is in #39253. The configuration/ASA branch is independent of this draft inheritance branch.Test Plan
make build— passed; regenerated bundles match the committed files.make lint— passed, 0 errors (191 warnings, 740 infos).main(7a8dec9b); verified the diff contains only the five inheritance-description source/bundle files.