Skip to main content

📄 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: the firstName + 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 by addressType, 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:
Once an employee is frozen, every card in their name declines transactions. Restricted states written by risk, regulatory or judicial processes cannot be lifted through this endpoint.

Request parameters

Request examples

Freeze (add restrictions):
Unfreeze (remove 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