You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is not clear what the intercom.contacts.find# method does relatively to intercom v2 API.
One would expect the method contacts#find to work when using external_ids just like the companies (which work using company_id): intercom.contacts.find(external_id: xxx). When using the library to find a user by its external ID, we're hoping to find a single user. In case of multiple users with the same external ID (is it possible in Intercom ?), the response should either throw an error (multiple matching user error) or return, to avoid confusion, a different class (like Intercom::ContactSearch or ContactList). When looking at the official REST API, the GET User endpoint seems to work only with intercom user IDs, but one could expect the Ruby gem to provide an abstraction to find users by external IDs as well.
I would have rather have a contacts.find_all method when searching for users using the search contact POST so the expected output would be an iterable list.
Is this some weird behavior introduced when migrating from v1 to v2 of the Intercom API ?
Actual behavior
The responses using contacts.find(id: xxx) and contacts.find(external_id: xxx) give two different data structures, yet they are of the same class (see example below in steps to reproduce)
Steps to reproduce
Here is an example where a call to the API returns 10 different users (they all have different external_id, but for some reason the call returns them all), and the response class is Intercom::Contact which is misleading, because it actually contains several users
Here is the same call retuning only one user as mentioned in the documentation
irb(main):018:0> single_rez = intercom.contacts.find(id: "6558e14xxxx")
=>
#<Intercom::Contact:0x000055ca4d1ef560
irb(main):019:0> single_rez.data
Traceback (most recent call last):
/usr/local/bundle/gems/intercom-4.2.1/lib/intercom/lib/dynamic_accessors_on_method_missing.rb:24:in `define_accessors_or_call': 'data' called on Intercom::Contact but it has not been set an attribute or does not exist as a method (Intercom::AttributeNotSetError)
irb(main):020:0> single_rez.class
=> Intercom::Contact
irb(main):021:0> single_rez.phone
=> nil
Logs
The text was updated successfully, but these errors were encountered:
Startouf
changed the title
Intercom find by external ID returns the same class with different interfaces
Intercom find by external ID returns the same class with different data structures
Nov 18, 2023
Version info
Expected behavior
It is not clear what the
intercom.contacts.find#
method does relatively to intercom v2 API.One would expect the method
contacts#find
to work when using external_ids just like the companies (which work using company_id):intercom.contacts.find(external_id: xxx)
. When using the library to find a user by its external ID, we're hoping to find a single user. In case of multiple users with the same external ID (is it possible in Intercom ?), the response should either throw an error (multiple matching user error) or return, to avoid confusion, a different class (like Intercom::ContactSearch or ContactList). When looking at the official REST API, the GET User endpoint seems to work only with intercom user IDs, but one could expect the Ruby gem to provide an abstraction to find users by external IDs as well.I would have rather have a
contacts.find_all
method when searching for users using the search contact POST so the expected output would be an iterable list.Is this some weird behavior introduced when migrating from v1 to v2 of the Intercom API ?
Actual behavior
The responses using
contacts.find(id: xxx)
andcontacts.find(external_id: xxx)
give two different data structures, yet they are of the same class (see example below in steps to reproduce)Steps to reproduce
Here is an example where a call to the API returns 10 different users (they all have different external_id, but for some reason the call returns them all), and the response class is
Intercom::Contact
which is misleading, because it actually contains several usersHere is the same call retuning only one user as mentioned in the documentation
Logs
The text was updated successfully, but these errors were encountered: