The TFNRegistry™ API sends the Customer Record Activation Notification (UNS-CRA) Unsolicited Message to Resp Orgs that have this message configured on the Activation Notice Control (GAN) page in the TFNRegistry.
The message is sent after all the affected SCPs have responded to TFNRegistry, downloading a Customer Record, or the number of attempts to contact the SCPs have expired. This is nominally within 15 minutes after first attempting to send the record to the SCPs.
The information in the message contains the overall status of the Customer Record and the status at each available SCP. For each SCP that responded, the date and time of the response is provided. The Customer Record sent in the UNS-CRA message can be a regular (standard) Customer Record, Pointer Record or a Template Record.
The notification is not sent if the reason for download is SCP Load.
End Point URL
/v3/ext/uns/cra
JSON Format
JSON message structure for UNS-CRA message.
{
“tfNum”: “”,
“tmplName”: “”,
“effDtTm”: “”,
“RespOrgId”: “”,
“msgId”: “”,
“origRespOrgId”: “”,
“custRecStat”: “”,
“custRecSize”: “”,
“apprStat”: “”,
“scpResult”: { => array of objects {
{
“scpId”: “”,
“result”: “”,
“dtTm”: “”
},
{
“scpId”: “”,
“result”: “”,
“dtTm”: “”
}
}
}
}
Parameter Descriptions
Table 3: UNS-CRA Parameter Descriptions
Table 3: UNS-CRA Parameter Descriptions |
|
Parameter |
Description |
tfNum |
Populated if the Customer Record is a regular Customer Record or a Pointer Record.
xxx-nxx-xxxx, where:
xxx = (NPA), 800 and other open 8xx codes nxx = (NXX) digits xxxx= (LINE) digits |
tmplName |
A unique template name which identifies the template, this contains the routing information for the Pointer Record.
15-character identifier starting with an asterisk (*). |
effDtTm |
The standard format for date and time is: YYYY-MM-DDTHH:MMZ
Effective Date and Time of the Customer Record that is sent in the notification. Please refer to the API Overview document for more information. |
respOrgId |
It is the Resp Org ID of the user. Alphanumeric (5). |
origRespOrgId |
The Resp Org that originated the transaction (e.g. if the CR activation was initiated by that Resp Org). For records updated via Batch Update, this field will be populated with the controlling Resp Org. If transaction is via Mass Change, then valid values indicating the type of Mass Change:
|
msgId |
10 digit alphanumeric string. Message ID of the REQ-CRC or REQ-CRA message. Populated only if the request was initiated by the TFNRegistry. |
custRecStat |
Status of Customer Record:
|
apprStat |
Approval status of the Customer Record:
|
custRecSize |
Size of the download message to the SCP. 7 bytes number |
scpResult ->{scpId} |
Name of an affected SCP (in Area of Service (AOS)). Alphanumeric (4). |
scpResult ->{dtTm} |
The standard format for date and time is: YYYY-MM-DDTHH:MMZ Date and time when SCP responded. Please refer to the API Overview document for more information. |
scpResult ->{result} |
The result of the send request to the affected SCP:
|
Notes:
- SCP, Result and Date Time parameters is sent for each SCP as a list.
- If the Status returned = 1 (sending) or 4 (failed - SCP rejection), the scp, res, and dt will contain for each SCP that should receive this record, the current result and the date and time of the result.
- If the Status returned = 2 (active) or 3 (disconnect), the scp, res, and dt fields will contain the final information for this Customer Record instance.
The custRecSize tag (field) will always be returned when the Status = 1 (Sending), 2 (Active), 3 (Disconnect) or 4 (Failed - SCP Rejection). For Status = 5 (Failed - SMS Revalidation) the crmsgsize field will be returned if failure of the record is due to the download message being too large. All other cases for Status = 5 and Status = 6 (Failed - Incorrect SMS status) or 7 (Failed - NOW reject) will not have the crmsgsize field. For Status = 6, some examples of a CR status being incorrect for being downloaded to SCPs are: the CR status is Saved or Invalid or Must Check and it reaches its Effective Date/ Time. For Status =7, an example is when a Resp Org sends a CR 'NOW' update and the CR needs Carrier Approval, then the CR initially goes INVALID and then goes FAILED when it gets processed for CR download.