What is the required attribute set for item creation (Getting SERVER ERROR 500)

mikesitmikesit Member Posts: 31

Hey Guys,

We are getting a server error 500 when trying to create new items. And this has us wondering... what are the required (minimum) attributes in order to create a new item.

Error returned:

{

"httpCode":"500",

"httpMessage":"Internal Server Error",

"message":"An error has occurred and we've been notified. Please try again and if this problem continues please contact support.",

"errorClass":"InternalServerErrorHttpException"

}

Endpoint we're calling:

https://api.lightspeedapp.com/API/Account/XXXXXX/Item


Payload provided: (the only properties we are initializing are customSku, description & CustomFieldValues)

{

 "itemID": 0,

 "systemSku": 0,

 "defaultCost": 0.0,

 "avgCost": 0.0,

 "discountable": false,

 "tax": false,

 "archived": false,

 "serialized": false,

 "description": "Test attrs on create 100",

 "modelYear": 0,

 "customSku": "100",

 "createTime": "0001-01-01T00:00:00+00:00",

 "timeStamp": "0001-01-01T00:00:00+00:00",

 "publishToEcom": false,

 "categoryID": 0,

 "taxClassID": 0,

 "departmentID": 0,

 "itemMatrixID": 0,

 "manufacturerID": 0,

 "seasonID": 0,

 "defaultVendorID": 0,

 "CustomFieldValues": {

   "CustomFieldValue": [

     {

       "customFieldID": 107,

       "name": "Dexterity",

       "type": "string",

       "value": "RHXXX"

     }

   ]

 }

}

Regards,

rock

Best Answers

  • LucienVersendaalLucienVersendaal Moderator, Lightspeed Staff Posts: 879 moderator
    Accepted Answer

    Hi @mikesit,

    Thank you for contacting us.

    I've tried the same structure of your payload and it was working for me. This is my payload what worked, compare this payload with yours and try again.

    {
          "defaultCost": "0",
          "discountable": "true",
          "tax": "true",
          "itemType": "default",
          "serialized": "false",
          "description": "New Product",
          "modelYear": "0",
          "upc": "",
          "ean": "",
          "customSku": "12341234",
          "manufacturerSku": "",
          "publishToEcom": "true",
          "categoryID": "1",
          "taxClassID": "1",
          "departmentID": "0",
          "itemMatrixID": "0",
          "manufacturerID": "0",
          "seasonID": "0",
          "defaultVendorID": "0",
          "CustomFieldValues": {
              "CustomFieldValue":[
                  {
                      "customFieldID": "4",
                        "type": "string",
                        "name": "Kleur_code",
                        "uom": "",
                        "decimalPrecision": "0",
                        "archived": "false"
                  }
              ]
        },
          "Prices": {
          "ItemPrice": [
            {
              "amount": "400",
              "useTypeID": "1",
              "useType": "Default"
            },
            {
              "amount": "275",
              "useTypeID": "2",
              "useType": "MSRP"
            },
            {
              "amount": "320",
              "useTypeID": "3",
              "useType": "Online"
            }
          ]}
    }
    

    I hope this helps.

  • mikesitmikesit Member Posts: 31
    Accepted Answer

    Thanks Lucien,

    That helped. It turns out that we did not omit required fields but instead included fields that subsequently cause the Server error ...

    We had to inhibit the serialization of the following properties in our class structure on a CREATE request:

    ItemID

    SystemSku

    Archived

    AvgCost

    CreateTime

    TimeStamp

    So, 1st: thanks, really glad we have this working but...

    Why does the API even look at properties it does not need to process the request context. I would think it should just ignore them if possible and not cause a debugging issue like this.

    The Item CREATE docs do make a subtle reference to the problem but only through the omission of those properties in the example... I would think this needs explicit documentation OR change the way the API does parameter validation.

    If I'm way off on this, my apologies... but it just seems wrong.

    Thanks again for the assistance,

    Rock

Sign In or Register to comment.