Card applications
Track a card application from submission to the card being produced.
getCreditApplicationIdByFromShadowCardNumber
Retrieves the credit application ID associated with a given ShadowCardNumber. If a replacement application exists, returns CorrelationId if available; otherwise, returns the RecordId as ApplicationId, along with the ApplicationDate.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCreditApplicationIdByFromShadowCardNumber › 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.
shadowCardNumberThe platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.
getCreditApplicationIdByFromShadowCardNumber › Responses
Success
applicationIdThe card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.
applicationDateA 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.
submitCardApplicationExtStatus
Submits the external status of a card application and returns the CardApplicationExtStatusHistoryRecordId for tracking the status.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
submitCardApplicationExtStatus › 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.
applicationIdCard application the status belongs to. Refused when absent and refused again when zero. Not checked against the application table — an id that matches no application is accepted and stored, so a typo arrives as a status row nothing will ever read.
externalStatusCodeThe application's status in the external system that owns the process — a card application originated outside the platform, tracked here against applicationId. One character, and the length is checked before anything is written rather than left to the column.
The codes are the submitting system's own. Nothing resolves this value against a parameter table or an enumeration: it is compared with the stored value for inequality and written through, so any single character is accepted. The one code the platform writes itself is X, set by the no-name application expiry batch when it cancels an expired pending application (alongside a cancellation reason of EXP). It carries no meaning the platform reads back, and a bank's own codes may use it or not.
Submitting any status has one side effect worth knowing: the expiry batch reads the last write to this record and, where there is one, measures a pending application's expiry from that date against the ExternalStatusExpirePeriod parameter instead of from the application date against DefaultExpirePeriod. So a status submission moves the clock the application expires on.
submitCardApplicationExtStatus › Responses
Submitted. cardApplicationExtStatusHistoryRecordId is the history row written for this change, and it is 0 when the submitted code equals the one already stored — that case writes nothing at all and is reported as a success, so a caller treating the id as proof of a write has to test it.
cardApplicationExtStatusHistoryRecordId