📄 Guide
Day-to-day maintenance after an employee has been created is covered by six endpoints: query the details, one update endpoint each for name / phone / email / address, and freeze/unfreeze. A name change triggers KYC re-submission; the other three do not touch KYC. Freezing and unfreezing use add/remove set semantics over capability codes. Creation and resubmission are covered in Creating employees; the full state machine is in State machine and freezing.Querying employee details
GET /open-api-corp/customer/v1/query
Returns the employee’s name, contact details, status and address list (once maintained).
Request parameters (query string)
Response data
addresses[] element structure:
Request example
Response example
Error codes
Updating employee information
Each of the four categories has its own endpoint. The path states the intent, the request carries only the fields that category needs, and the error codes returned are only the ones that category can hit:
All four are action endpoints: on success they return
SYS_SUCCESS with data set to null.
Updating the name
The name is replaced as a whole: thefirstName + middleName + lastName submitted become the new legal name, with no per-part merging — KYC compares the complete name, and only a whole-name submission makes what goes to review unambiguous. Omitting middleName means there is no middle name, and any previous value is cleared. The call either fully succeeds or fully fails; there is no partial success.
Updating the mobile number
The country code and the number must be submitted together. This number also serves as the delivery contact for physical cards.Updating the email address
Updating addresses
The update is “partial byaddressType, whole by object”: only the address types present in the request are affected, types left out are untouched, and a type that is matched has its whole object replaced. Field-level edits are not supported.
An address update only affects later virtual-to-physical applications — the address is snapshotted into the application when it is accepted, so cards already in transit or delivered are unaffected.
Freezing and unfreezing (updating employee restrictions)
POST /open-api-corp/customer/v1/update-restrictions
Freeze or unfreeze an employee. The semantics match the organization side exactly: adding a restriction freezes, removing it unfreezes, with idempotent set semantics that make repeated submissions safe. Only the five open L1 capability codes are accepted:
Request parameters
Request examples
Freeze (add restrictions):Error codes
Related webhook:
CUSTOMER_STATUS_CHANGED, with businessId set to customerId and data carrying this change’s addRestrictions / removeRestrictions and remark.
Next steps
- Once the employee is
ACTIVEand not frozen, issue and manage their cards: Managing cards - The full employee state machine and freezing capabilities: State machine and freezing

