Answered

Search by Date field return wrong items (e.g. contacts/search by "created_at")

M
Badge +1

eq-respempty-respHello, looks like there is a bug in Search API.

 

I've created a few contacts today and one of them have "created_at" equal to 1602494086.

But when I try to search like this:

 

```

"query": {

"field": "created_at",

"operator": ">",

"value": 1602494080

}

```

 

it returns nothing.

According to docs (search-for-contacts) value from query will be interpreted as start of the day so it's still a valid query and should return this contact.

 

What's strange: when I use operator "=" in query it return multiple items including the requested one, e.g. :

 

{

"field": "created_at",

"operator": "=",

"value": 1602494080

}

 

So, looks like there is a problem in operator logic

 

Thanks in advance for any help!

 

Attaching few screenshots from the postman:

icon

Best answer by Roy 14 October 2020, 20:46

View original

10 replies

R
Rank
Userlevel 1
Badge

Hello @misha​ , It's not a bug.

 

First of all, the value should be in ("-") and the second one:

timespaminfoMore info can be found here.

 

M
Badge +1

@roy s11​ Thanks for the reply, BUT:

1) I've tried putting value in "" and it doesn't work. Still I can't get the contact

2) As you may've noticed I've already mention the note you attached to the answer and the main reason of this question is that it doesn't work for me.

 

Please take a look at the attached screenshots. On the second you can see that the created date is greater than queried one. And it's okay since date is interpreted as beginning of the day.

But according to that logic the query from the first screenshot should return the same contact since ">" works as greater or equal according to docs.

 

Am I wrong here?

gt_respeq_resp

M
Badge +1

By the way, the date that is used in search query is equal to "Mon, 12 Oct 2020 00:00:00 GMT"

and the created_at from contact is equal to "Mon, 12 Oct 2020 08:39:40 GMT"

 

So query

{

field: "created_at",

operator: ">",

value: "1602460800"

}

should return all contacts that were created after "Mon, 12 Oct 2020 00:00:00 GMT", Am I right?

 

R
Rank
Userlevel 1
Badge

@misha​ , Sorry, missed your text 😞 I check now and "=" is even not supported for timestamps.

 

"For example, if you search for all Contacts with a created_at value greater than 1577869200 (the UNIX timestamp for 2020-01-01 @ 09:00), that will be interpreted as 1577836800 (2020-01-01 @ 00:00). The search results will then include Contacts created between 00.00 and 09.00 on 2020-01-01."

 

So for 2 day's result, I Take a 3-day timestamp and use the following request:

=========================================

{

 "query": {

  "operator": "AND",

  "value": [

   {

    "field": "created_at",

    "operator": ">",

    "value": "1600905600"

   }, 

   {

    "field": "created_at",

    "operator": "<",

    "value": "1601078400"

   }

  ]

 }

}

=========================================

And it's worked for me.

If you want results for 1 day, you should take from and to timestamps for that.

M
Badge +1

Sorry, but still can't fully understand the logic of how to get contacts specifically after 1602460800 :(

 

I've just tried this query

 

{

"query": {

"operator": "AND",

"value": [

{

"field": "created_at",

"operator": ">",

"value": "1602460800"

},

{

"field": "created_at",

"operator": "<",

"value": "1602547200"

}

]

}

}

 

And it doesn't return items between them.

 

It begins to work only when I use created_at from previous day, i.e. 1602460799 (11 Oct 23:59:59 GMT). So looks like ">" works here as `Greater` instead of `Greater or Equal`.

M
Badge +1

FYI: for conversations it seems to work better. Looks like '>' still works as 'greater' instead of 'greater or equal'. Please take a look at screenshots for more details.

conv_gtconv_gte 

M
Badge +1

@roy s11​ sorry for disturbance but maybe you have some more tips for me?)

R
Rank
Userlevel 1
Badge

@misha​ , Hah, Sorry sometimes missing posts here 

 

The best way here to ask about this Intercom support from messenger or wait here until someone from the Intercom team reply to you.

 

When I'm using a data filter with "From -> To" it's working fine. 

 

You are asking "Looks like '>' still works as 'greater' instead of 'greater or equal"

In Intercom documentation, cleary said: 

 

"This means you can only query for timestamp fields by day - not an hour, a minute, or second"

 

That's why you are not getting exact results for "1602624758; 1602624759". 

 

My advice was to use date to date to get a result:  

=========================================

{

 "query": {

  "operator": "AND",

  "value": [

   {

    "field": "created_at",

    "operator": ">",

    "value": "One date"

   }, 

   {

    "field": "created_at",

    "operator": "<",

    "value": "Two date"

   }

  ]

 }

}

=========================================

If this not works in your case, you should contact Intercom support or wait the answer from an Intercom employee here. 

 

Sorry that I missed your post.

M
Badge +1

Hm...strange but looks like now it works as described for new contacts. But I still can't get this particular contacts using start of their day.

 

By 'greater or equal' I meant that according to docs date in search query transforms to the start of the day '00:00' and for me it worked only when I asked the end of previous day like '23:59'.

 

Anyway, thanks for the contribution!

V

@roy s11​ Hey ,

I am also facing similar kind of issue. what happened in my scenario is that is as below (API V is 2.3).

  1. As per docs intercom save timestamp data in UTC format
  2. when I pass the UTC timestamp to search API sometimes is does not return any result , but at the same time I pass the timestamp of my local region I got requested data . sometimes it happen vise-versa
  3. in GET All CONTACT API - when requested sometimes data come in ASC order despite mention order=DESC key in query-params

 

I am not sure what is happening at server but I am sure about format date from ISO string to UTC timestamp.

 

Please kindly provide help.

Reply


Terms & ConditionsCookie settings