Context:

I’m using the Intercom <=> Jira cloud integration to link my Intercom Conversations and Tickets to related Jiras.

A limitation with this integration is that it doesn’t write the Jira ID to the Intercom data objects, it writes to a Jira field ‘linked_intercom_conversations.’ This means I can’t search or do any reporting in Intercom for Conversations/Tickets related to Jiras.

To solve this, I wrote a tool to pull the Intercom IDs from the Jira fields, and update a data attribute in Intercom with the Jira ID that was linked.

Here’s the problem:

When the ‘linked_intercom_conversations’ is written to the Jira it always writes the url ID to the  field. This means that all of the linked objects look like conversations. Because Intercom doesn’t share data attributes across conversations and ticket types, it takes a different API call to update a ticket vs a conversation. But I can’t tell from the ID on the Jira which type is is.

I tried doing a call to api.intercom.io/conversations/CASEID, and on tickets there is sometimes a ticket value in the response that contains the ticket.id, and sometimes not. Specifically, when I run the same call from within the AirTable scripting environment where I’ve build the automation, the ticket object is not included in the response, but running the same call from Postman, I see it.

interestingly the “type’ value is ALWAYS “conversation,” even if it’s a ticket.

I need some help here to either figure out why the AirTable script is not getting the full response, or to find another way to identify if something is a ticket or a conversation from the ID provided by the Jira integration.

Thanks for any help if y’all have insights!