I also see an issue in src/rest/bulkexports/v1/export/job.ts:

49f3f2b#diff-5a4d9d347825dc80283179a0537726bed59c467114fdbefac69d0b4d73329a0bR409

This type should be Record<string, any>[] because the API returns the following structure for job.details:

[
  {
    status: 'Submitted',
    count: 3,
    days: [ '2025-03-07', '2025-03-08', '2025-03-09' ]
  }
]

The same invalid types remain as of v5.5.2

I'm also seeing an issue with broken types as a result of this commit: 49f3f2b

The issue I'm encountering is similar to the one @codygordon posted but on ParticipantInstance.

Old type prior to v.5.5.0: messaging_binding: any;
Broken type introduced in v5.50: messaging_binding: Record<string, object>;
Expected type: messaging_binding: Record<string, string>; or messaging_binding: Record<string, any>;

Same here. A few erroneous types were introduced including:

• DocumentInstance.data: Record<string, object>;
• FlexFlowInstance.integration: Record<string, object>;

Hello! Thanks for raising the issue. We will look at it on priority basis.

Hi, we are experiencing a similar issue with the types field on the SubscriptionListInstanceCreateOptions interface, which was updated from Array<any> to Array<object> type. Now when trying to create a subscription, we get the following error Error: Input list of Types cannot be empty.

We have reverted our twilio client version back to 5.2.2, before this change, and things are working as expected, but it would be great to get this fixed, assuming this is indeed the root issue here.

We experienced the same issue: Input list of Types cannot be empty above. We reverted to version 5.4.5 and I noticed the same change noted above, appearing to be the culprit.

It looks like the provided objects are no longer stringified using (e: any) => serialize.object(e) as they were before. (See serialize.object() functionality)

Hi! So as these helpers are autogenerated from the public open api specs, due to a recent update these changes have been introduced. I see the best way in most of the above cases would be to use Record<string, any>. In case of encryption_details, where the expected datatype should be Record<string, any>[], I'll check with the product team to update the spec accordingly so that we can generate them correctly. I'll raise a PR to preview these changes and once finalized, they should be available in the next release. Thanks!

Please review #1090 and let me know if there are any issues. Thanks!