OpenAPI Generation Errors

Steven Cinquegrana

Beginning with the release of the Events API (beta) and Payments API and continuing with the new NXT Data Integration API, we've started to see OpenAPI code generation errors specific to enumerations.


For example, from the NXT Data Integration API, instead of (differences highlighted):

namespace SKYLib.DataIntegration.Model
{
    /// <summary>
    /// Defines PhoneNumberType
    /// </summary>

    [JsonConverter(typeof(StringEnumConverter))]
    public enum PhoneNumberType
    {
        /// <summary>
        /// Enum TelephoneNumber for value: TelephoneNumber
        /// </summary>
        [EnumMember(Value = "TelephoneNumber")]
        TelephoneNumber = 1,

        /// <summary>
        /// Enum FaxNumber for value: FaxNumber
        /// </summary>
        [EnumMember(Value = "FaxNumber")]
        FaxNumber = 2,

       ...
   }
}

We're seeing:

namespace SKYLib.DataIntegration.Model
{
    /// <summary>
    /// Defines PhoneNumberType
    /// </summary>

    public enum PhoneNumberType
    {
        /// <summary>
        /// Enum TelephoneNumber for value: TelephoneNumber
        /// </summary>
        TelephoneNumber = TelephoneNumber,

        /// <summary>
        /// Enum FaxNumber for value: FaxNumber
        /// </summary>
        FaxNumber = FaxNumber,

        ...
    }
}

We've tried changing our code generator version and such but then we run into other errors, so we've stuck with our current version.


Would someone please advise if there is a difference in how you're generating definitions between APIs?


We see this error with the Event API Invitation Status model, the Payments API Account Type model and quite a few in the new NXT Data Integration API (eg Country Code, Phone Number Type, Country Currency Placement) and a few others but these examples should be sufficient to locate and hopefully rectify the problem.

NOTE: Even within the same API we don't see the problem with all enumerations, just some.


Without a fix, we have to code up generation corrections, which we do for other things but it shouldn't really be necessary for these problems.


Let me know if you need more details.


Cheers,

Steve Cinquegrana | CEO and Principal Developer | Protégé Solutions