Customers
Read the customer behind the cards — portfolio summary, corporate relationships and total assets.
getAssetByShadowCardNumber
Retrieves debit card asset information based on the ShadowCardNumber. Calls the CIS service proxy to fetch details and maps them to GetAssetByShadowCardNumberResponse, including Bin, ProductNumber, OwnerSearchName, CardRefNumber, CardStatusCode, CardStatusReasonCode, CustomerNumber, EmbossName, ExpiryDate, InsertDate, InsertUserId, MainCardRefNumber, MainCustomerNumber, MaskedCardNumber, MaskedPanAlternative, OwnerName, OwnerSecondName, OwnerSurname, PSN, ServiceDomainId, and SupplementaryCard flag.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getAssetByShadowCardNumber › Request Body
shadowCardNumberThe card whose asset record is read.
getAssetByShadowCardNumber › Responses
Success.
This is the cardholder-facing view of a card — the owner's name in three parts, the emboss name, the status and its reason, whether it is a supplementary card. Like getCardByCardNumber it does not guard against the service answering nothing. It takes no channel.
customerNumberThe customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.
supplementaryCardWhether this is a supplementary card rather than a main one.
mainCustomerNumberThe main customer of a corporate relationship, as a number. The employees and supplementary holders under it carry their own customerNumber.
insertDateWhen the row was created.
A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.
serviceDomainIdValues:
01— credit02— debit03— prepaid
ownerNameThe cardholder's first name, as the customer record holds it.
maskedCardNumberThe card number with its middle digits masked, as the platform stores it. It is a display form, not a key: operations take the shadow number.
ownerSecondNameThe cardholder's middle name, where there is one.
ownerSurnameThe cardholder's surname, as the customer record holds it.
psnbinThe bank identification number — the leading digits of the card number that name the issuer and the product range.
cardStatusCodeValues:
A— validB— pendingC— stolenD— cancelled by the bankF— fraudG— temporarily blockedI— cancelledL— lostM— cancelled by the customerT— corporate dummy
cardStatusReasonCodeproductNumberThe card product the card is issued on. Defined in the parameter tables; getCardProductList returns the ones a tenant may use.
cardRefNumberThe card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.
maskedPanAlternativeA second masked form of the card number, masked differently for a channel that needs other digits.
mainCardRefNumberThe card reference of the main card. On a supplementary card this is the card it hangs from; on a main card it is the card's own reference.
ownerSearchNameThe cardholder's name normalised for searching — accents and case removed. It is not the name on the card.
insertUserIdWho created the row, as the platform recorded it.
getCustomerDetail
Retrieves detailed customer information, including personal, firm, and contact details. Accepts GetCustomerDetailRequest containing CustomerNumber, Channel, CommCompanyCode, and flags for including address, email, GSM, and phone details. Returns GetCustomerDetailResponse with a Customer object containing MasterInformation, PersonalInformation, FirmInformation, ListOfAddress, ListOfEmail, ListOfGSM, and ListOfPhone. Calls _cisServiceProxy.GetCustomerDetail() and maps the response to internal data structures. Null is returned if the customer does not exist.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCustomerDetail › Request Body
channelThree-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.
customerNumberCustomer to read. It is not checked for zero or a negative value.
getEmailDetailFalse leaves the e-mail list out of the response altogether.
getAddressDetailFalse leaves the address list out of the response altogether.
getPhoneDetailFalse leaves the phone list out of the response altogether.
getGsmDetailFalse leaves the mobile number list out of the response altogether.
commCompanyCodeRestricts the address, e-mail, mobile and phone lists to records carrying this company code. When absent the code mapped to channel is used, falling back to the platform default.
getCustomerDetail › Responses
Success.
A customer number that matches nothing is not an error. The operation answers 200 with an empty body rather than reporting that the customer was not found.
Only the master information is guaranteed. The personal and corporate blocks are fetched inside a catch: if that lookup fails the failure is logged and both blocks are simply absent from the response, which looks the same as a customer that has neither.
Each of the four communication lists is fetched the same way. A failed lookup is logged and swallowed, so an absent list can mean the flag was false, the lookup failed, or the customer genuinely has no such records.
The four lists are filtered by company code: records whose company code differs from the resolved one are dropped, so the response can omit communication records that exist on the customer.
createCustomer
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
createCustomer › Request Body
channelThree-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.
Customer data. The main block inside it is mandatory as well.
Address, GSM, e-mail and phone records created alongside the customer. Each list is validated up front and written after the customer master row.
createCustomer › Responses
Success.
Only customerNumber and personId come back. Everything else the service derives - the customer status, the register row, the communication record identifiers and the log entries - is written but not returned.
customer.limit is dropped by the integration layer, so the customer is always created with a zero credit limit and a zero cash advance limit whatever the request asks for.
The customerNumber on every entry in communications is overwritten with the number the customer was created under, so an entry cannot attach records to a different customer.
When customer.main.isLite is true the service forces the customer type and the value segment code to the lite defaults and clears the value sub-segment code, overriding whatever the request supplied.
The customer master row and its creation log are written before the communications are processed, and the one-default-address, one-card-address and one-contact-number checks run at that point rather than during validation. A request rejected by one of those checks can therefore leave a customer master row behind with no personal, corporate or register row.
customerNumberThe customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.
personIdThe person behind the customer record.
updateCustomer
Update Customer
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
updateCustomer › Request Body
channelThree-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.
Customer data. The main block inside it is mandatory as well.
Communication records. Every entry is created as a new record; see the 200 description.
updateCustomer › Responses
Success.
Only customerNumber and personId come back. The operation does not report which fields it changed, and a request that changes nothing answers exactly the same way as one that changes everything.
Every entry in communications is written as a new record rather than an update. The integration layer does not forward recordId, updateAllData or validFlag, so the service always takes its create path: it inserts a new address, mobile number, e-mail address or phone number and leaves the existing ones untouched. Because of that the create-path rules apply, and the one-default-address, one-card-address and one-contact-number counts include the records already stored for the customer, so sending an address flagged isDefault for a customer that already has a default address is refused.
For most fields a null, or a blank string, means keep the stored value. Two fields break that pattern: customer.segment.valueSubSegmentCode is written unconditionally, so omitting it or omitting the whole segment block clears the stored sub-segment, and customer.preferences.customLimitationFlag falls back to the stored sensitive data permission flag when it is null.
customer.persona is written only if the customer already has a personal information record, and customer.corporate only if it already has a firm information record. For a customer without one the block is still validated and then silently discarded. The customer's citizenship number is never changed by this operation, and customer.main.externalCustomerNumber and customer.corporate.authorityCustomerNumber are not written either.
The communication records are written before the customer master row is modified.
customerNumberThe customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.
personIdThe person behind the customer record.