V5 Nullability seems... wrong?

[shortstuffsushi]

Checklist

• I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

With V5, it appears that every single field on responses is nullable. Up to and including the ID field on any given element. This can't possibly be correct, and because I know that some of these fields are non-null, I've in some places added asserts or ?? '' because I know they'll be there, but making everything optional means, simultaneously, that I have no idea what is actually optional. Here is one simple example -

export interface CreateOrganizationInvitationResponseContent {
    id?: string;
    organization_id?: string;
    inviter?: Management.OrganizationInvitationInviter;
    invitee?: Management.OrganizationInvitationInvitee;
    ...
}

An invitation will always minimally have an id, an org id, and an invitee - right? I think many of the rest of these are non-null too, but consider these as a starting point. Additionally, the Invitee and Inviter objects both have their properties as non-null, which feels odd?

Describe the ideal solution

Please update the type definitions to accurately reflect nullability. The type files say you're using Fern to generate them from an API - maybe one or both of those need to be updated to address this?

[spdaley]

We are curious about this as well. As part of our migration I've had to liberally spread usage of ! to indicate I know the field is defined. At first I was thinking that maybe it was due to the fact with read calls you can generally pass a "fields/select" option and you can potentially ignore some of these fields. So they could be null. But I don't think you can do with create and update calls and their responses are also defined to return undefined. Here's another example:

export interface UpdateOrganizationResponseContent {
    /** Organization identifier. */
    id?: string;
    /** The name of this organization. */
    name?: string;
    /** Friendly name of this organization. */
    display_name?: string;
    branding?: Management.OrganizationBranding;
    metadata?: Management.OrganizationMetadata;
    token_quota?: Management.TokenQuota;
    /** Accepts any additional properties */
    [key: string]: any;
}

How is it possible to not have an id for an organization in the response to the update call?

[frederikprijck]

The SDK is built on top of the Open API specification file, which does define all fields for CreateOrganizationInvitationResponseContent as non-required, see: https://auth0.com/docs/api/management/openapi.json

There's a big chance the same applies for other's you are encountering.

The Open API specification file is not GA, and we do expect some improvements to happen to it and potentially follow up with other major SDK versions as needed (but they will not be structurally different as v4 vs v5, but will mostly come down to per-endpoint or type improvements). I am not aware if the required aspect of it would be tackled specifically, or if this is intended.

I have raised this internally, but from the looks of it the SDK does work as intended.