I have inherited some old (functional) code that uses SFCT_<n> names as typeIds in the secondary fields section, but your documentation only talks about typeids with meaningful names like DATE_OF_BIRTH_TYPE_ID. Are the old ones deprecated to be removed at some point in the future? Could you point me at documentation regarding the old names? Is there something we have to alter in our code to use the new type ids?
For a deeper look into our World Check One API, look into:
3
●0 ●1 ●3
SCFT_2 vs DATE_OF_BIRTH_TYPE_ID in worldcheck one API
@mani.biju
Thank you for your participation in the forum. Are any of the replies below satisfactory in resolving your query? If yes please click the 'Accept' text next to the reply that best answers your question. This will guide all community members who have a similar question. Otherwise please post again offering further insight into your question.
Thanks,
-AHS
Hello @mani.biju
Thank you for your participation in the forum.
Is the reply below satisfactory in resolving your query?
If so please can you click the 'Accept' text next to the appropriate reply. This will guide all community members who have a similar question.
Thanks,
AHS
4.2k
●8 ●5 ●6
Please find the screenshot of the documentation which explicitly mentions the same idea I tried to convey in my previous post.cusersu6068964picturesnew-foldercapture.png
4.2k
●8 ●5 ●6
We still use SFCT_<n> names as typeIds in the secondary fields section. The type id for the date of birth is SFCT_2. This attribute is still the same and we do not plan to deprecate them.
The correct JSON to use SFCT_2, i.e, to pass the date of birth of the individual is given below.
"secondaryFields":[
{
"typeId":"SFCT_2",
"dateTimeValue":"1998-09-23"
},
]
That being said, you can use as many secondary identifiers in your JSON payload like gender, nationality, place of birth, etc. For example:
"secondaryFields":[
{
"typeId":"SFCT_1",
"value":"MALE"
},
{
"typeId":"SFCT_2",
"dateTimeValue":"1998-09-23"
}
]
Currently we support only 5 secondary identifiers:
{
"typeId": "SFCT_1",
"label": "GENDER"
},
{
"typeId": "SFCT_2",
"label": "DATE_OF_BIRTH"
},
{
"typeId": "SFCT_3",
"label": "COUNTRY_LOCATION"
},
{
"typeId": "SFCT_4",
"label": "PLACE_OF_BIRTH"
},
{
"typeId": "SFCT_5",
"label": "NATIONALITY"
}
You can get the above information using the API call "SEQ-pre-group-case-template: Get the case template for a group"- /caseTemplate endpoint.
Request you to download the latest postman collection and the API documentation v1.5 using the link below. You can find how to use secondary identifiers while saving or sync screening a case in the scheme reference document available in the API documentation.
3
●0 ●1 ●3
so from your docs:
- Example INDIVIDUAL secondary fields
1. GENDER
{
"typeId":"GENDER_TYPE_ID",
"value":"MALE"
}
It suggests that the type id for gender is 'GENDER_TYPE_ID' not 'SFCT_1' ?
4.2k
●8 ●5 ●6
I understand that the value of type id for gender provided is "GENDER_TYPE_ID" in the API documentation. However, kindly note this does not mean that you can use this value when saving a case or sync screening it. This only suggests that you will have to use a value that corresponds to "GENDER_TYPE_ID". So in this case, the type ID for gender is SFCT_1 (which is indeed a GENDER_TYPE_ID) and for DOB is SFCT_2.
You can get the correct value for the GENDER_TYPE_ID using the API call
"SEQ-pre-group-case-template: Get the case template for a group"- /caseTemplate endpoint.
