@Eclairemoy — Wow, this is a huge update!

We're especially excited to see the robust typing and the auto-pagination.

On the pagination front, we had done some gymnastics to make something work using higher order functions, but it felt kludgy. I didn't know this type of looping is possible... This is a lot cleaner.

With our own internal services, we've found the type checking to help a lot across networking boundaries, as we've discovered too many errors when something changes over the wire.

Quick question... How does the typing interplay with the version selection? In other words, if different versions emit different data structures, does that mean that changing the version number (e.g. 1.0 vs 2.0 will cause the library to return different types?

Tiny API question... Since you're moving to positional parameters plus options hashes, would it make sense for IntercomClient to be initialized with the token as a first positional param?

Overall though, this looks like a big step up and it's great to see Intercom doubling down on the API front. It will make it easier for us to integrate it with our other systems as we adopt more AI-based support workflows.

I'm a founder and my company is currently a client of Intercom. We're on one of the paid plans. I just migrated to this new SDK release (took maybe 10 minutes) so here's my feedback.

Overall, it feels like this SDK update is much more modernized. The previous SDK wasn't even an ES module so I'm glad to get rid of the old import style. The type updates and new inline documentation were super helpful while migrating methods to the new format--I don't remember seeing that on previous versions. Other than that, not much changed for me. Just converted some camelCase arguments to underscore format and I was good to go.

Building an SDK is easy, but keeping it up-to-date is the hard part. The previous SDK felt like it was kinda neglected so hopefully Intercom can keep this quality up going forward.

I'm going to start using this in prod and will report back if anything unexpected comes up. Very happy with the update so far though!

We use Intercom here at Thera. We have to build integrations on a monthly basis, so seeing a Typescript client that has pagination with an iterator and declarative version selection is music to my ears. We're not going to start using this until it's promoted from alpha to a stable version.

@Eclairemoy, you have a timeline for that?

I just tried beta3, and I encountered an issue that makes it somewhat troublesome to use. Why are all fields in each object defined as nullable/optional? When I retrieve a contact object, there are certain fields that are always to be present. However, because the type declaration makes all fields nullable, I have to add code to check these fields; otherwise, TypeScript throws an error.

Hello @Eclairemoy CTO credal.ai here, we're working on an Intercom integration but are not going to start until we can depend on the V6 Node SDK. When do you expect it to be released? This will be very helpful for our engineering planning and what we can push for our customers interested in intercom.

Hi @Eclairemoy,
This new SDK looks very promising. I especially appreciate the addition of Types and Auto-pagination—great work! However, I’ve encountered an issue with Auto-pagination. It seems to work correctly for companies but not for collections.

Here’s an example that works as expected:

const page = client.companies.list()
for await (const company of page) {
  console.log(company.id);
}

But with collections, it doesn’t seem to work:

const page = client.helpCenter.collections.list()
for await (const collection of page) {
  console.log(collection.id);
}

I also tried a workaround by explicitly passing the page number and per_page parameter, but it seems to have no effect:

const page = client.helpCenter.collections.list({page: 2, per_page: 25});

Could you clarify the correct way to handle pagination for collections? Or is this a known issue?

Thanks in advance!