Admin id is a String, but Contact owner_id (which references an Admin) is an Integer — why the type mismatch? | Community
Skip to main content
Answered

Admin id is a String, but Contact owner_id (which references an Admin) is an Integer — why the type mismatch?

  • April 7, 2026
  • 2 replies
  • 137 views
T

I noticed what looks like a type inconsistency between two related schemas in the REST API.

On the Admin object (/admins/admin), the id field is defined as a string — and the example values in the docs reflect this (e.g. "493881", "1295").

However, on the Contact object, the owner_id field — which the docs describe as "the id of an admin that has been assigned account ownership of the contact" — is defined as an integer.

These two fields represent the same value (an admin's ID), but they're typed differently depending on which side of the relationship you're looking at. This creates a few practical problems:

  1. Strict-typed languages choke on this. If I model Admin.id as a string and Contact.owner_id as an integer (matching the docs), I can't do a straightforward equality check without casting one or the other.
  2. Search filter confusion. When using the Search Contacts endpoint and filtering by owner_id, should I be passing a string or an integer? The field type says integer, but the actual admin ID is documented as a string.
  3. Serialization edge cases. Depending on the JSON parser, "493881" (string) and 493881 (integer) are not equal, which can cause subtle bugs in integrations.

Is this an intentional design choice, or is it a documentation inconsistency? If the admin ID is truly a string under the hood, should owner_id on the Contact schema be updated to reflect that?

Would love to hear from the team or anyone else who's run into this. Thanks!

https://developers.intercom.com/docs/references/rest-api/api.intercom.io/admins/admin

https://developers.intercom.com/docs/references/rest-api/api.intercom.io/contacts.md

https://developers.intercom.com/docs/references/rest-api/api.intercom.io/contacts/contact

Best answer by Karla T

Hi ​@Tanner Helton 👋  Karla here from the community team here! 

Great catch, and thanks for laying this out so clearly. You’re absolutely right to call out the inconsistency here.

What’s happening is that admin IDs are stored as integers internally, but the Admin API returns them as strings in responses, for example "1295". On the Contact object, the owner_id field returns that same value as an integer instead. So while both fields represent the same ID, they come back in different formats.

 

To answer your questions:

This is not an intentional design choice. It is an inconsistency in how the data is exposed across endpoints.
For filtering on owner_id in the Search Contacts endpoint, passing the integer value is the safest approach today since that is how it is stored and indexed.
From an integration perspective, the most reliable approach is to normalize the value on your side before comparing. Converting everything to strings is usually the safer long-term option.

I’m going to create a conversation internally to flag this with our team and get more clarity on whether there are plans to standardize this behavior. I’ll keep you updated as soon as I hear back.

Really appreciate you flagging this. This kind of detail is incredibly helpful.

2 replies

Karla T
Intercom Team
Forum|alt.badge.img+1
  • Karla TIntercom Team
  • Intercom Team
  • Answer
  • April 18, 2026

Hi ​@Tanner Helton 👋  Karla here from the community team here! 

Great catch, and thanks for laying this out so clearly. You’re absolutely right to call out the inconsistency here.

What’s happening is that admin IDs are stored as integers internally, but the Admin API returns them as strings in responses, for example "1295". On the Contact object, the owner_id field returns that same value as an integer instead. So while both fields represent the same ID, they come back in different formats.

 

To answer your questions:

This is not an intentional design choice. It is an inconsistency in how the data is exposed across endpoints.
For filtering on owner_id in the Search Contacts endpoint, passing the integer value is the safest approach today since that is how it is stored and indexed.
From an integration perspective, the most reliable approach is to normalize the value on your side before comparing. Converting everything to strings is usually the safer long-term option.

I’m going to create a conversation internally to flag this with our team and get more clarity on whether there are plans to standardize this behavior. I’ll keep you updated as soon as I hear back.

Really appreciate you flagging this. This kind of detail is incredibly helpful.

Karla T | Leading Community at Intercom
Karla T
Intercom Team
Forum|alt.badge.img+1
  • Karla TIntercom Team
  • Intercom Team
  • April 21, 2026

Following up here in case others run into this as well 👋

We raised this with our engineering team to better understand the type mismatch between admin_id (string) and contact.owner_id (integer). After reviewing, they confirmed that this isn’t something they’re planning to change right now.

As a workaround, you can cast the value to your desired type on your end when handling the data.

We know inconsistencies like this can be frustrating, and we really appreciate it being called out. The team is continuing to improve the product over time, so this is something that could be revisited as priorities evolve. Thanks again for flagging it!

Karla T | Leading Community at Intercom
Terms & ConditionsAccessibility statement