FIFA Connect ID Service exposes a set of REST API methods. Every scenario that can be achieved via SDK can be also achieved directly by the use of API (Hashing API, ID Directory API, Service Bus API). SDKs in .NET, Java and PHP that Connect ID provides, use that API layer under the hood.

If so, an MA whose NRS is built in technology other than supported (e.g. in Python) could expect that choosing a direct integration via API will be a viable option for them. This is, however, not a recommended approach. You can read more about our recommendations here as this article only explains the challenges of the "via API" integration.

If one chooses to integrate directly via REST API, they will basically need to cover all aspects of the integration that have been covered by Connect ID technical team when developing SDKs, e.g.:

  • integration with Azure Active Directory (authentication & authorization)
  • encryption/decryption of messages in Service Bus

  • person registration (single operation in SDK but multiple operations without it)

  • etc.


Below you will find two examples showing how much simplified the integration will be, should you choose to make use of the existing SDKs.


Example 1 - Person registration (no duplicates found, very simple scenario)


    with SDK:

  • create PersonData object containing both person information and information about registration (e.g. football professional registration)
  • call RegisterPersonAndWaitForDuplicates method


    via REST API:

  • create PersonData object
  • call ComputeHashes method of the API to get the list of hashes for the first name, last name and date of birth
  • call RegisterPerson method of the API giving list of hashes and other person information as parameters
  • call AddRegistration method of the API to add registration to a newly registered person


Example 2 - Person registration (duplicates found, difficult but quite frequent scenario)


    with SDK:

  • create PersonData object containing both person information and information about registration (e.g. football professional registration)
  • call RegisterPersonAndWaitForDuplicates method
  • read the returned object and display the details of all duplicates returned to the user of your FMS


    via REST API:

  • create PersonData object
  • call ComputeHashes method of the API to get the list of hashes for the first name, last name and date of birth
  • call RegisterPerson method of the API giving list of hashes and other person information as parameters
  • catch 409 (duplicates found) error and read the basic information about each duplicate
  • for each duplicate you now need to send request for person details to another MA via Service Bus
    • calculate the queue name of the recipient MA
    • create a Message object
    • download the public certificate of recipient MA
    • encrypt the message
    • send your message via Service Bus and remember CorrelationID returned
    • assuming that you have implemented the listener, keep checking your queue for the return message
    • when the message arrives, download it from the queue, check its type and decrypt it if correct
    • save the details of the duplicate and continue until you receive details of all potential duplicates from different MAs
    • remove the message from the queue
  • read the returned object and display the details of all duplicates returned to the user of your FMS


In fact even this extensive list of operations that need to be performed without SDK, is simplified. It assumes that you have implemented and run a listener component responsible for sending & receiving messages from the Service Bus. Authorization topic was not discussed either, but your application will of course need to authenticate with REST API and Service Bus component (via Azure Active Directory). Sending out messages to different MAs should be done asynchronously, otherwise the performance will be affected. Things like error handling or logging cannot be forgotten either.

All in all, developing the whole integration from scratch without using any of the SDKs under the hood, will be a significant effort and instead we recommend to use one of the approaches described here.

If, despite the recommendation, a Client chooses to pursue the direct integration with API, they will find the following resource useful as it includes the code snippets: Direct API integration (proof of concept).

Reading about all these difficulties one might ask a question: why is Connect ID Service built in a way that it needs a thick client (SDK)? Why haven't all those abovementioned complexities been hidden on the server side behind the REST API? This would definitely be a valid question. The answer is personal data protection. To follow the privacy be design principle of the Connect Programme we needed to ensure that FIFA_ID cannot be correlated with first and last name of the person being registered. Therefore it is the client that needs to implement a logic of first contacting a Hashing service and then, after being returned the results, sending hashes to ID Directory service to get a FIFA_ID.


If you are interested to know more about this topic contact us by opening a ticket or sending an e-mail to support.id@fifa.org.