SDK Settings

ExternalID

If you have an internal ID connected to the session on your side, you can send this as externalID to link your ID with the application created via the SDK.

There are no checks performed on this external ID, which means it can be used in multiple verifications. For example, if a user fails the first verification, you can use the same externalId in the next one.

Some examples of ID:s that are common to send as externalID:

Internal sessionID
Unique userID
Email address connected to user account

// Basic example from the GetID webSDK integration section including external ID

const config = {  
  apiUrl: 'https://[PARTNER].getid.ee',  
  jwt: jwtToken,  
  containerId: 'checkin-component',
  flowName: '[FLOW]',  
  locale: 'en',  
  
  metadata: 
  {
    externalId: '123456', // Your internal identifier 
  },  
  
}

// Basic example from the GetID native iOS section including external ID

GetIDSDK.startVerificationFlow(
  apiUrl: "API_URL",
  auth: .jwt("JWT"),
  flowName: "FlowName",
  locale: 'en',
  metadata: .init(externalId: "123456")
)

// Basic example from the GetID native Android section including external ID

Map<String,String> metadata = new HashMap<>();
metadata.put(exteralId, "123456");

new GetIDSDK().startVerificationFlow(
                getApplicationContext(),
                "API_URL",
                new Token("JWT"),
                "FlowName",
                metadata,
                "en",
                null,
                null
        );

// Basic example from the GetID native Android section including external ID

GetIDSDK().startVerificationFlow(
    context = applicationContext,
    apiUrl = "API_URL",
    auth = Token("JWT"),
    flowName = "FlowName",
    locale: 'en',
    metadata = Metadata(externalId = "123456")
)

Custom Labels

The metadata object can also be used to pass custom labels to attach to an application.

Labels are basic key-value pairs that can be set to anything as long as they are strings. Attached labels are available in the metadata section on the application.

// Basic example from the webSDK integration section including custom labels

const config = {  
  apiUrl: 'https://[PARTNER].getid.ee',  
  jwt: jwtToken,  
  containerId: 'checkin-component',
  flowName: '[FLOW]',  
  locale: 'en',  
  
  metadata: 
  {
    labels: {
    	 'email': '[email protected]',
    	 'brand': 'brand1',
  		}
  },  
}

Profile Data

If you have collected data from the user before the verification flow starts, you can pass it to the SDK as profile data to cross-check with data extracted from the documents.

For example: If you pass first and last name in the profile object, each name will be cross-checked with the first and last name extracted from the document. If there is a mismatch between the names, this will be flagged and the application status will be set accordingly.

Data sent in profile should follow a basic format and consist of

category- The name of the field you want to cross-check. The name of the category needs to be identical to the name of the field extracted from the document.
value- The value you want to cross-check. The expected format of the value depends on the category. For some fields it is just a free text string, for others there is an expected format that should be followed (e.g. for Date of birth it should be YYYY-MM-DD)

// Basic example from the GetID webSDK integration section including profile data

const config = {  
  apiUrl: 'https://[PARTNER].getid.ee',  
  jwt: jwtToken,  
  containerId: 'checkin-component',
  flowName: '[FLOW]',  
  locale: 'en',  
  
  profile: 
  [{   
    value: 'Joe',  
    category: 'First name',  
  }, 
  {  
    value: 'Doe',  
    category: 'Last name',  
  },  
  {  
    value: '1990-01-20',  
    category: 'Date of birth',  
  }],
  
}

// Basic example from the GetID native iOS section including profile data

GetIDSDK.startVerificationFlow(
  apiUrl: "API_URL",
  auth: .jwt("JWT"),
  flowName: "FlowName",
  locale: 'en',
  profileData: .init(["first-name": "John", "last-name": "Doe"])
)

// Basic example from the GetID native Android section including profile data

Map<String,String> profileData = new HashMap<>();
     profileData.put("first-name", "John");
     profileData.put("gender", "male");

new GetIDSDK().startVerificationFlow(
                getApplicationContext(),
                "API_URL",
                new Token("JWT"),
                "FlowName",
                null,
                "en",
                profileData,
                null
        );

// Basic example from the GetID native Android section including profile data

GetIDSDK().startVerificationFlow(
    context = applicationContext,
    apiUrl = "API_URL",
    auth = Token("JWT"),
    flowName = "FlowName",
    locale: 'en',
    profileData = mapOf("first-name" to "John", "last-name" to "male")
)

Accepted Documents

The default documents you want to support is configured for each flow via your backoffice. This configuration can also be overwritten directly in the SDK config object in case you need this.

An example of a scenario could be that you are supporting a different set of documents for each market you operate in, and rather than having one flow for each market, you can still use the same flow but simply set the accepted documents dynamically when initiating each session.

// Basic example from the GetID webSDK integration section including setting accepted documents

const config = {  
  apiUrl: 'https://[PARTNER].getid.ee',  
  jwt: jwtToken,  
  containerId: 'checkin-component',
  flowName: '[FLOW]',  
  locale: 'en',  
  
 acceptableDocuments: (supportedDocuments) => {
        const desiredCountries = ['swe']; // A list of countries can be provided: ['swe','est']

        return supportedDocuments.map(({ country, documentTypes }) => {
          if (desiredCountries.includes(country.toLowerCase())) {
            return {
              country,
              documentTypes: documentTypes.filter((x) => x === 'id-card' || x === 'passport'),
            };
          }
          return null; // Exclude documents from undesired countries
        }).filter(Boolean); // Remove null entries
      }
    });
  
}

`onFail` callback

In addition to the onComplete callback, there is also the onFail callback which can be captured in case something goes wrong during the verification process.


const config = {  
  apiUrl: 'https://[PARTNER].getid.ee', 
  jwt: jwtToken, 
  containerId: 'checkin-component', 
  flowName: '[FLOW]',  
  locale: 'en',  
  
  onComplete( data ) {  // catch when an application has been successfully completed
      console.log("All was good")  
      console.log( data.applicationId );  
    }, 
  onFail( data ) {  
      console.log("Something failed")  // catch if something went wrong
      console.log(data.code, data.message);  
    },
};

`onClose` callback

By defining the onClose callback, you add a close button to the IDScan modal. This is useful if you are embedding the IDScan somewhere and the user should be able to close it.


const config = {  
  apiUrl: 'https://[PARTNER].getid.ee', 
  jwt: jwtToken, 
  containerId: 'checkin-component', 
  flowName: '[FLOW]',  
  locale: 'en',  
  
  onComplete( data ) {  // catch when an application has been successfully completed
      console.log("All was good")  
      console.log( data.applicationId );  
    }, 
  onFail( data ) {  
      console.log("Something failed")  // catch if something went wrong
      console.log(data.code, data.message);  
    },
    onClose( data ) {  
      console.log("User pressed close button")  // Code to hide the modal
      console.log(data.code, data.message);  
    },
};