Skip to main content

📄 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

(The example omits some cash-advance period nodes for brevity; a real response carries all four.)

Error codes

Updating a rule

POST /open-api-corp/velocity/v1/update-rulefull replacement: any dimension or control group absent from the request is deleted, and the change takes effect on bound subjects immediately.
An update is a full submission, not an incremental merge: omitting remark clears it; omitting a control group deletes that group (which means no limit); currency groups absent from amountLimits are deleted. At least one of the five control groups must still be present — to disable a whole rule use the enable/disable endpoint, do not clear its control groups. Call query-rule first to fetch the complete configuration, modify it, and submit the whole thing.
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”.
On top of the rule-creation error codes, an update can return:

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.
Before disabling, use bindingCount from the response to warn the customer: this rule currently constrains N subjects, and they will no longer be controlled by it.

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