Weird result on SearchResults API

App Development
1

Hi,

I use the Pipedrive SearchResult API to search for persons from the phone.
It’s ok for most cases.
But, I don’t understand some results that seem wrong.

An exemple :
I search persons with number 0660938839
The api returns one contact with this phone 0493886840

The matched_queries is phone_local_startsWith

Is this result normal for this matched_query ?
If so, what is the explanation ?

Thanks for your responses !
Regards,
Rémi MOINAS

2

Does the contact have any additional numbers that it might be matching with?

Also, do you have any other examples similar to this so I can do some testing?

3

Hi,

Sorry for the delay.
So, i make several tests on my sandbox account and i managed to reproduce the bug.
On this sandbox : ringover-sandbox-ebdb05

I made this HTTP request
GET https://api.pipedrive.com/v1/searchResults?term=0670938868&item_type=person
And the result is the contact id 95 with this phone : “04 93 88 68 39” (phone_local_startsWith)

Other test
https://api.pipedrive.com/v1/searchResults?term=0660938868&item_type=person
And the result is the contact id 95 with this phone : “06 70 93 88 68” (phone_local_default,phone_local_startsWith)

Contacts have no other phone numbers.

Thanks for your responses !
Regards,
Rémi MOINAS

4

Thanks @SaphirAngel,

It does appear to be a bug. I’ll let you know once it is resolved

5

This should be resolved now.

6

Thanks for response and debug.

Unfortunately, the problem is not totally resolved. The previous examples are ok, but i can create other examples.
If i made this HTTP request :
GET https://api.pipedrive.com/v1/searchResults?term=0678655524&item_type=person
The result is the contact id 97 with this phone : “0248655524” (phone_local_default,phone_local_startsWith)

What is the problem due to ?

Thanks for your responses !
Regards,
Rémi MOINAS

7

It’s an issue with older numbers inserted into PD, but it should have been resolved completely for your account. I will have one of our developers take another look tomorrow.

8

Hi Rémi,

So the issue with this last example isn’t exactly a bug.

0678655524 is found with 0248655524 because internally we store the phone number in 2 ways: the international number (as it is inserted) and a local number (with international prefixes removed, where available). In this case 0678655524 is recognized as an international number with international phone number identifier 0678 (a leading 0 is a common in Europe, Asia, Australia and New Zealand as the identifier for international phone numbers and 678 is the international dialing code for the island state Vanuatu).

The 0678 is stripped from the front of the number, leaving 655524 as the local phone number. Similarly, your stored phone number 0248655524 is stored both as 0248655524 (international number with 0+248 recognized as an international phone number for Seychelles) and a local phone number 655524, which matches your search term’s local phone number.

Is this a real use case you’ve ran into or did it just come up during testing? 2 phone numbers matching (minus the international code) in 2 different countries has been a very rare case so far.
The reason why this logic exists is so when users store an international number, they can still search for it using the local number and the other way around. Being able to search for the same number with a different country’s international prefix is a minor side effect of it.

9

Hi David,

Thanks for this very detailed answer.
I understand better why this gives inconsistent results.
The use case that I described comes from a feedback from a client.

So I’m going to do a double check on my side.
It’s annoying because it forces me to make a second request to retrieve all the numbers of a contact. But if I have no choice, it’s ok

But on your side, why not take into account the international format E164 ?
And I believe that numbers in international format start mainly with +, 00 or 011 and not only the character 0 which represents a national number.
Example : 00 countryCode Nationnal_number_without_leading_0 (0033601711227 for a French number in international format)

10

Per one of our developers behind this:

“While the E164 standard is great, US uses a single leading 0 much like Europe uses + . Since we have a lot of customers in the US, we’ve opted to interpret the leading 0 as an international number prefix like we have the leading + in Europe.”