Has Intercom considered implementing a GraphQL API?


Is Intercom considering to provide (or has considered) a GraphQL endpoint/API?

I think this would be a major benefit for many many third-party integrations. Personally, I still struggle with the existing REST API endpoints not providing enough information or no easy access to the resources that I require (see my post in: I have a feature request for the REST APIs). As a result, I am forced to send a whole bunch of requests to get the data that I need.
A GraphQL endpoint (even just for reading data) would immediately fix these problems because I can specify in the request to the GraphQL server all the data that I require.



Hey @tobi! It has been considered and we even spiked it once, but doesn’t seem something hugely impactful for the short term. Happy to be challenged on this :slight_smile:

Would you be able to share why you think GraphQL would help with “providing enough information”? The benefit of query language is to have easier ways to filter data, like having any kind of parameter. Lack of information in the current resources wouldn’t be improved with GraphQL as far as I know. Is there something missing you are looking to get access to?



Hey @hellojeanpierre, thanks for your reply! First of all, I want to make clear that I think from a REST API design point of view there is nothing wrong with the REST API itself. The problem I am referring to is inherent to REST APIs.

Essentially my statement about “providing enough information” refers to nested resources in the REST API response. I think the benefit of a GraphQL API is most apparent in the flexibility of the read APIs and the ability to control the shape of the response.

For example /conversations/{id} returns:

  • the conversation data, incl all conversation parts
  • references to users and admins as ids across conversation and conversation parts

With the REST API I have to make these requests:

  1. /conversations/{id}
  2. extract author and user ids
  3. send another 2 requests to /admins/{id} and /users/{id}

In my case I actually only require basic conversation details plus user and admins involved by name. All the conversation parts are over-fetched whereas author and user are under-fetched.

With a GraphQL API I can make a single request that may look like this:

query {
    conversation(id: {id}) {
        conversation_message {
            author {
        user {

The result includes all the information that I require without any follow-up requests + exculdes all the fields that I don’t require.

I see the main benefit of a GraphQL API in the flexibility of selecting exactly the data that I need and leaving out whatever I don’t need. I also moves a lot of the complexity from the API user to the GraphQL server that is probably closer to the data itself and has much more possibilities to compose and optimize for efficient queries.

I hope this make sense.



Thanks @tobi for the insightful reply. That makes sense!

We’re aiming to improve rate limits in the short term which should help with multiple requests, I’m also keen to look at other solutions if rate limits are regularly hit in certain situations. GraphQL is something in the horizon but I can’t see it happen before end of year.



@hellojeanpierre sounds good :+1: I think higher rate limits are definitely gonna help. For now, I managed to wrap some parts of the REST API with a GraphQL server myself. At least it offloads some of the complexities of resolving dependent objects to the GraphQL server implementation. I will add some caching to that to avoid excessive amounts of API requests to Intercom.