Calling AccountingApi.GetContactAsync throws an ApiException wrapping a JsonSerializationException when a contact has an address with AddressType: "DELIVERY":
Xero.NetStandard.OAuth2.Client.ApiException: Error converting value "DELIVERY" to type
'Xero.NetStandard.OAuth2.Model.Accounting.Address+AddressTypeEnum'.
Path 'Contacts[0].Addresses[2].AddressType', line 39, position 35.
at Xero.NetStandard.OAuth2.Client.CustomJsonCodec.Deserialize(HttpResponseMessage response, Type type)
at Xero.NetStandard.OAuth2.Client.CustomJsonCodec.Deserialize[T](HttpResponseMessage response)
at Xero.NetStandard.OAuth2.Client.ApiClient.Exec[T](HttpRequestMessage req, IReadableConfiguration configuration, CancellationToken cancellationToken)
at Xero.NetStandard.OAuth2.Client.ApiClient.GetAsync[T](String path, RequestOptions options, IReadableConfiguration configuration, CancellationToken cancellationToken)
at Xero.NetStandard.OAuth2.Api.AccountingApi.GetContactAsyncWithHttpInfo(String accessToken, String xeroTenantId, Guid contactID, CancellationToken cancellationToken)
Root cause
Xero.NetStandard.OAuth2.Model.Accounting.Address.AddressTypeEnum (used by Contact.Addresses) only defines POBOX, STREET. The live API returned AddressType: "DELIVERY" for a real contact's address, which this enum doesn't recognize, and the whole contact fails to deserialize as a result. Confirmed this is unchanged across every published version from 13.0.0 up to the latest 18.1.0. Upgrading doesn't fix it.
Per Xero's own Types and Codes docs, DELIVERY is described as the delivery address of the organisation, settable only via purchase order creation in the Xero app. It isn't documented as a valid value for Contact.Addresses at all. So either the API is returning an undocumented value for this field, or the docs are stale. Either way, the SDK shouldn't hard-fail deserialization of an entire contact over one address's enum value it doesn't recognize.
To Reproduce
I have not been able to reproduce creating an address with AddressType: DELIVERY on a Contact via the Xero UI or API. I only observe this when reading back existing data from live customer organisations via GetContactAsync. The deserialization failure is my only evidence that such data exists. I don't know how these addresses were created (possibly legacy/migrated data, or a contact type/flow outside the normal UI). If a maintainer can point to how a Contact ends up with a DELIVERY address, that would help me and future readers of this issue avoid it. Regardless of cause, the SDK shouldn't hard-fail deserialization of an entire contact over one address's enum value it doesn't recognize.
Expected behaviour
Contact.Addresses[].AddressType should either accept DELIVERY (if it's genuinely possible on live Contact data), or the deserializer should tolerate an unrecognized enum value for one address without failing the entire response.
SDK version: 13.0.0 (also reproduced against 16.0.0, 17.0.0, 18.1.0)
Calling
AccountingApi.GetContactAsyncthrows anApiExceptionwrapping aJsonSerializationExceptionwhen a contact has an address withAddressType: "DELIVERY":Root cause
Xero.NetStandard.OAuth2.Model.Accounting.Address.AddressTypeEnum(used byContact.Addresses) only definesPOBOX, STREET. The live API returnedAddressType: "DELIVERY"for a real contact's address, which this enum doesn't recognize, and the whole contact fails to deserialize as a result. Confirmed this is unchanged across every published version from 13.0.0 up to the latest 18.1.0. Upgrading doesn't fix it.Per Xero's own Types and Codes docs,
DELIVERYis described as the delivery address of the organisation, settable only via purchase order creation in the Xero app. It isn't documented as a valid value forContact.Addressesat all. So either the API is returning an undocumented value for this field, or the docs are stale. Either way, the SDK shouldn't hard-fail deserialization of an entire contact over one address's enum value it doesn't recognize.To Reproduce
I have not been able to reproduce creating an address with
AddressType: DELIVERYon a Contact via the Xero UI or API. I only observe this when reading back existing data from live customer organisations viaGetContactAsync. The deserialization failure is my only evidence that such data exists. I don't know how these addresses were created (possibly legacy/migrated data, or a contact type/flow outside the normal UI). If a maintainer can point to how a Contact ends up with aDELIVERYaddress, that would help me and future readers of this issue avoid it. Regardless of cause, the SDK shouldn't hard-fail deserialization of an entire contact over one address's enum value it doesn't recognize.Expected behaviour
Contact.Addresses[].AddressTypeshould either acceptDELIVERY(if it's genuinely possible on live Contact data), or the deserializer should tolerate an unrecognized enum value for one address without failing the entire response.SDK version: 13.0.0 (also reproduced against 16.0.0, 17.0.0, 18.1.0)