Archived field logic doens't make sense.

maurisource

From the API Docs, endpoints such as 'Customers' support "archived" field which is a (boolean) type.

However, by default this field always returns "false" matching records in GET Response.

Records matching "true" is never returned by the GET Response.

Scenario to reproduce: From my account, I delete CustomerID: 12

Current API response:

       {
           "firstName": "Customer",
           "lastName": "Eleven",
           "dob": "2001-05-20T07:00:00+00:00",
           "title": "EAT A W...it's so satisfying ",
           "company": "Employee",
           "companyRegistrationNumber": "",
           "vatNumber": "",
           "creditAccountID": "25",
           "customerTypeID": "3",
           "discountID": "0",
           "taxCategoryID": "0",
           "customerID": "11",
           "createTime": "2019-04-23T22:44:15+00:00",
           "timeStamp": "2019-05-28T23:29:52+00:00",
           "archived": "false"
       },

Expected API response:

       {
           "firstName": "Customer",
           "lastName": "Eleven",
           "dob": "2001-05-20T07:00:00+00:00",
           "title": "EAT A W...it's so satisfying ",
           "company": "Employee",
           "companyRegistrationNumber": "",
           "vatNumber": "",
           "creditAccountID": "25",
           "customerTypeID": "3",
           "discountID": "0",
           "taxCategoryID": "0",
           "customerID": "11",
           "createTime": "2019-04-23T22:44:15+00:00",
           "timeStamp": "2019-05-28T23:29:52+00:00",
           "archived": "false"
       },
       {
           "firstName": "Customer",
           "lastName": "Twelve",
           "dob": "2019-04-25T07:00:00+00:00",
           "title": "Bass player",
           "company": "",
           "companyRegistrationNumber": "",
           "vatNumber": "",
           "creditAccountID": "47",
           "customerTypeID": "0",
           "discountID": "0",
           "taxCategoryID": "0",
           "customerID": "12",
           "createTime": "2019-04-24T17:18:31+00:00",
           "timeStamp": "2019-05-20T22:11:28+00:00",
           "archived": "true"
       },

As you can see customerID:12 is inexistant from the GET Response.

As a result it's impossible to pull records that are in "archived" state

Can the someone explain the logic behind that or confirm if it's a BUG ?

gregarican

I tested this out and it works. Pulling both customer records that are active and those that have been archived. Give this a shot!

https://api.merchantos.com/API/Account/{AccountId}/Customer.json?archived=IN,[true,false]

maurisource

@gregarican

Thanks for the reply It does work when adding ?archived=IN,[true,false] to the URI endpoint.

But I'm afraid altering the URI isn't a valid solution in my production environment.

I don't think it makes sense that by default the API returns false matching records only.

Let's take a look at 'Item' endpoint.

We have boolean "discountable" or "publishToEcom" for example. Both return values that are "true/false". There's no need to specify anything. Got my point?

gregarican

Good point. By the same token, if you query the Item endpoint, by default does it only show non-archived records? Similar to the Customer endpoint's default behavior you've noted? If so, then at least there's some consistency to the inconsistency :)

Long-term it would behoove Lightspeed's API developers to clean up things so it's more consistent. There are many examples --- property values that are null are sometimes excluded entirely from the API response, properties that can contain an array of values will return a singleton (not an array with one member) if there is only a single value, not all endpoints you'd expect allow PUT or POST operations such as Workorders, etc.

maurisource

@gregarican

The issue mentioned is API-Wide, affecting the "archive" field. It's the only one I've encountered so far that is defaulting to Return "false" values.

I would be nice to know what the API team thinks on the matter.

PS: Yes I've encountered the same issues with singleton and incoherent documentation typos..