📄 Guide
A subject may be constrained by several rules at once; the system merges them by taking the strictest value per dimension to produce the “effective limits”.query-quota returns that merged result together with current usage, and the platform has already computed the remainder for you. Rules themselves are adjusted through update-rule (full replacement) and change-rule-status (enable/disable), and inspected through query-rule and list-rules. Rule creation is covered in Creating velocity rules; the merge model is introduced in Limits and statements.
Querying effective quota
GET /open-api-corp/velocity/v1/query-quota — the merged effective limits and current usage for a subject (card / employee).
Request parameters (query string)
The quota object: the key to reading the response
Every period node in the response (daily / monthly / quarterly / yearly) is a “quota object”. The amount side and the count side use different field names but map one to one:
The per-transaction limit is the exception: the
perTransaction quota object carries only limitAmount and sourceRuleId — per-transaction limits do not accumulate, so there is no usage, remainder, utilization rate or period key.Response data structure
Response example
Error codes
Updating a rule
POST /open-api-corp/velocity/v1/update-rule — full replacement: any dimension or control group absent from the request is deleted, and the change takes effect on bound subjects immediately.
The request carries the same five control groups as rule creation; only the top level differs:
The response
data is the complete updated rule object (same structure as the create response) with ruleVersion incremented.
An unconfigured control group comes back as
null, not an empty object — an empty object would read as “an empty list was configured”.Enabling and disabling a rule
POST /open-api-corp/velocity/v1/change-rule-status — toggles between ACTIVE and INACTIVE. An INACTIVE rule takes no part in transaction checks but keeps its existing bindings, so re-enabling restores the constraints without unbinding anything.
The response
data carries ruleId, ruleName (so the client can confirm it changed the right rule), status (after the change), ruleVersion (the new value, required for the next update), bindingCount and modifyTime.
Querying rule details and lists
Detail:GET /open-api-corp/velocity/v1/query-rule — pass organizationId + ruleId to get the complete rule object (same structure as the create response, including ruleVersion, bindingCount and the five control groups). If the rule does not exist or does not belong to the organizationId supplied, the call returns VELOCITY_RULE_NOT_FOUND.
List: GET /open-api-corp/velocity/v1/list-rules — paged query of the organization’s rules, summaries only.
The response
data is the standard paging envelope: page / pageSize / total + result[], each entry carrying ruleId, ruleName, status, bindingCount and modifyTime.
total is a number while bindingCount is a string — the latter is declared as a boxed Long and the serializer emits it as a string. Parse them separately.Next steps
- Adjusting bindings (bind, unbind and the two-way queries): Binding and unbinding
- How limits participate in the authorization path: Transaction authorization and 3DS

