I have a feature request for the REST APIs

Feature-Request

#1

Have an idea for a new API endpoint? Need to see other data in the response from a certain endpoint? This is the place to talk about feature requests for anything that you’d like to see in future versions of our REST APIs. Just start a new reply here. Our Platform PMs regularly browse and reply on this thread.


#2
  1. Ability to see conversation tags without having to load entire conversation (e.g., in conversation list API) OR webhook topics for conversation tagging.
  2. User/company update (all or specified attributes)

#3

Thanks Murad! Number 1 make sense to me but can you elaborate on number 2 a bit more?


#4

Sure. I’m from Statbot, and we have to keep user/company list in sync with Intercom. Currently, we use scroll every day to iterate over all users and update their attributes (last seen, segments, tags, custom attributes - you get it). However, it is highly inefficient for customers with huge user base (hundreds of thousands or millions of users).
One solution would be to use classic user list API with ‘updated_at DESC’ sorting, but we’re afraid that those huge customers will hit the 10k list limit (e.g., more than 10k users logged in while we were processing the previous updated batch).
So, such a webhook would allow us to keep relevant user info up-to-date in real-time and not worry about limits or whatever. It would make sense to be able to subscribe to all attribute updates or only specific ones (say, we care only about last_seen_at, so we don’t want any other updates)


#5

One more thing, user classic list API has ‘created_since’ filter which accepts a number of days. We’re currently working on a solution that uses that filter to bypass the 10k list limit, but it won’t work if there’s more than 10k users signups on one day. It would be awesome if you added another ‘created_since’ filter that accepts a timestamp as the argument. Then the 10k a day limit wouldn’t be an issue.


#6

Oh, and I think you guys have it somewhere since we’ve been talking about it for a while, but for the sake of consistency I’ll leave it here: ability to subscribe to all events webhook. Currently, it’s possible to subscribe only to a list of event names, and that introduces several problems (in case it’s desirable to subscribe to all events):

  1. It’s up to the developer to construct the list of all event names, and there’s no quick way in the API to get it
  2. When a new event type is introduced, there’s no way to know about it in real-time

#7

Thanks @murad.yusufov this stuff is all super helpful! :slight_smile:

cc/ @hellojeanpierre


#8

Hey @murad.yusufov, thanks for sharing your feedback :raised_hands: Both things are on top of mind for us.

1- There is work done on how tagging works at Intercom. Right now tags are stored in each conversation part, we query max 500 parts so if we bring this at conversation list and depending on the page size it could be too much load. The solution is to store tags in conversation model rather than the part, other teams are looking into solving tagging from a product perspective before we can solve it in the API. We’ll have soon a webhook for conversation tagged, I can add Statbot to the beta.
2- We’re also looking at a webhook for lead/user/company update, but won’t happen a few months in. Our webhooks service needs some improvements before we can enable this topic, apparently the frequency of updates is way too high and would put all our webhooks at risk.


#9
  1. Conversation tagged webhook beta? Sounds awesome, yes, please!

  2. Absolutely, it makes sense that such a webhook would have to fire a lot. I was also thinking of alternate ways to reduce the amount of users we have to process daily, and got a little idea. Say, if the API were to add ‘updated_since_timestamp’ filter, we could user that filter and order by updated_at ASC to process only previously unprocessed users. However, that approach is flawed since it introduces a race condition that could lead us to losing some data, so it won’t work unless there’s some sort of list level MVCC, i.e., when we make the first request to the list with ‘updated_since_timestamp’ the list is locked and all consecutive list calls receive data as if those calls were made at the same moment as the first one.


#10

It would also be cool to be able to access the data around saved replies, e.g., what saved replies there are, when have they been used, edited / not edited, etc.


#11

As a +1 – We use the ‘updated_at DESC’ approximately every 10 minutes and routinely hit the 10K limit when a customer bulk-tags 10,001+ users in one operation – we fallback to a scroll at the end of that day but we can’t “reach” the 10,001st user in any efficient manner. @jeff @murad.yusufov


#12

@brian-chameleon Scroll needs a big rework, it’s quite janky given we are using ElasticSearch’s scroll. We’ll be looking at solutions after the summer and probably replace it with something better.


#13

Hi all,

These two features would greatly simplify my Intercom REST API usage (and reduce # of request to the API server):

  1. Search or filter mechanism
    In my case, I often have to fetch a specific set of conversations or users/leads by id. Because there is no endpoint for this, I usually have to send a request for each user/lead/conversation. Obviously, this is more error prone and slower than fetching a selection in a single request.
    The easiest solution to this might be a filter on id for the “list” resources of conversation/user/lead (selection via query parameters).

  2. Including Nested Resources
    I would be super useful to have a way to tell the API to include nested resources. E.g. when I fetch a conversation I only get ids for user, author, customer, etc. If I want any of these as well I might have to send another request for each of them. If I could tell the API to also include user, author, customer I could save a bunch of follow-up request to get that data as well.

The lack of these two features forces me to make quite a lot of API requests that would otherwise not be necessary. Hope that makes sense.


Has Intercom considered implementing a GraphQL API?
#14

I’d love to see the API support:

  • adding/removing tags from a conversation
  • listing conversations with a given tag
  • webhook when a tag is added/deleted for a lead

#15

@jeff and @hellojeanpierre - We’d love the ability to pause auto messages via the REST API.

As context, we are building a messenger app that allows product managers and designers schedule user interviews. As part of the configure flow in this messenger app, which is embedded in an auto message, a teammate can specify the number of participants they want to recruit. After the set number of participants are recruited, we’d love the ability to pause the auto message so that it’s not shown to more end users than needed.

Please hit me up with any further questions.

Thanks


#16

Maybe a ridiculous request, but the ability to create auto-messages from the API would be really helpful for us. Because of the restriction that an auto-message can only be sent to a person once we’ve ended up having to create multiple messages to cover each occurrence of an event in our app.

I assume it’s not really within the scope for Intercom to do this but the messages tell us so much about the user journey and re-engagement that we don’t really want to move these messages to another platform :frowning:


#17

The ability for the API to accept and properly handle CORS preflight requests would be great. As far as I can tell it isn’t possible to access the REST API directly from a SPA because any preflight OPTIONS request will return 404.

I think this would be really useful for people creating simple utilities (where it is not really necessary to have a server-side component).

In my specific case I would love to add the ability to manipulate custom_attributes via my internal tools portal.