Deprecation Timeline

Following a timetable of the deprecation that will be introduced in the future and how to mitigate impacts on your integration.

Trustfull strives to maintain backward compatibility, so any change that could be considered breaking is always introduced to cover any blind spots in unintended use cases.

2025-03-31: DEVICE AND BROWSER API REMOVAL

Device and browser API functionality is scheduled for removal on 2025-03-31

The change:

Following the deprecation, the device and Browser API are scheduled for removal and will no longer be available after 2025-03-31

Will this impact my API integration?

If you're using the device or browser claim in your API integration all calls will fail after the removal date.

How to mitigate this situation:

Reach out to your customer support specialist to better asses your use case and find a possible solution.

2025-03-31: WEBHOOK REMOVAL

After the deprecation of the webhook functionality in 2024 we reached the EOL for this feature.

The change:

After moving to a sync API integration, the webhook was left only to support some customers who were still using this integration method. Now, all customers will need to look at the API response rather than resorting to the webhook functionality.

Will this impact my API integration?

If you're relying on the webhook to receive data youn won't receive any data points on the provided endpoint, also the API will return status code 400 when passing the webhook URL.

How to mitigate this situation:

Since the webhook was available when calling the sync API endpoint rather than discarding the API response you can just look at the response and store the data.

Alternatively, you can wait for the API response and then forward the response to your webhook endpoint.

Please note that you will need to remove the webhook endpoint from the call parameters.

2025-01-29: JS-SDK REMOVAL

Following our deprecation schedule starting from 2025-01-28 we will no longer support the collection of data via the JS-SDK for the onboarding solution or onboarding related product.

The change:

The JS-SDK and the connected endpoints will be disabled.

Will this impact my API integration?

If you are using the JS-SDK as data collection you will not be able to see any data in the platform.

How to mitigate this situation:

Move to API integration, to know more about how to perform an API call to Trustfull's onboarding solution you can go here: API REFERENCE

2024-06-01: PROFILE INTEGRATION

Following our deprecation plan for the customer_id identity merge. We will not support multiple calls on the same customer_id even in the form of a profile integration.

What is a profile integration?

Profile integration is when an API request is sent to our system with a subset of data.

API CALL 1 -> customer_id_000 + PHONE + EMAIL

API CALL 2 -> customer_id_000 + IP

Currently, we perform a merge of the two requests into the same customer_id (in this case customer_id_000)

Resulting in an identity with PHONE + EMAIL + IP

The change:

In the API request, multiple subsequent calls with the same customer_id will not be supported.

For this reason, we're now enforcing a new customer ID for every API call.

Profile integration will be deprecated and will be removed at the specified date.

After the removal date, you will receive a 400 BAD REQUEST.

Will this impact my API integration?

This change is possibly breaking for your integration if:

• You make multiple API calls with the same customer_id and incrementally provide products.

How to mitigate this situation:

• Whenever a profile integration is necessary provide a new customer_id

2024-05-01: PHONE API WITH FIXED_LINE/LANDLINE

Calls made to fixed lines using our Phone API will be rejected by the system.

Will this impact my API integration?

• Your integration will be affected if you call the phone API or the onboarding solution using

The change:

Trustful prioritizes the digital footprint and online presence, and fixed lines do not offer the meaningful information required to accurately assess an identity's quality.

{
"status": "ko",
"message": "Landline are not supported for the phone api. Only mobile phone numbers are supported for scoring and enrichment. If you are call the onboarding solution you can retry this call by removing the phone claim and phone_number from the call",
"errors":  {"phone_number" : "..."]
}

How to mitigate this situation:

Whenever you receive this error you can retry the call removing the phone claim and the phone_number. If the API call is specific to the "phone" product there is no mitigation.

2024-04-01: multiple claims without "score"

A call with multiple claims without the claim score will not be supported anymore.

The change:

An example of such a call is:

{
  customer_id:'...',
  email: '...',
  phone_number: '...',
  claims: [
     'phone',
     'email'
  ]
}

Will this impact my API integration?

This change is possibly breaking for your integration if:

• You make a call to individual products bundled in a single API call.

How to mitigate this situation:

There are two possible ways to mitigate this change:

1. Use the claim 'score'. The resulting call will be similar to :

{
  customer_id:'...',
  email: '...',
  phone_number: '...',
  claims: [
     'phone',
     'email',
     'score'
  ]
}

2. Make two separate calls

Call 1: This is a call to the PHONE API:

{
  customer_id:'...',
  phone_number: '...',
  claims: [
     'phone'
  ]
}

Call 2: This is a call to the EMAIL API:

{
  customer_id:'...',
  email: '...',
  claims: [
     'email'
  ]
}

2023-08-01: Multiple API requests with the same customer_id

Our identity document was never meant to contain a history of changes in the customer touchpoints.

Even a single new touchpoint could have a significant impact on the digital score.

The change:

In the API request, different touchpoint values will no longer be supported for the same customer_id.

For this reason, we're now enforcing a new customer ID whenever we detect a change in previously collected data. This applies to all input including:

• email
• phone_number
• IP
• user_agent

We're still supporting the profile integration meaning that you can provide a new value if there was none before.

An example is providing a value for an email address during a multi-step signup process.

Will this impact my API integration?

This change is possibly breaking for your integration if:

• You make multiple API calls with the same customer_id
• You change a previously submitted value

How to mitigate this situation:

• If applicable don't update a previously submitted customer_id with new values, ideally you will generate a random customer ID for each new request.
• Whenever an update is necessary provide a new customer_id.