Is there a specific reason why Response Headers are not accessible from data that is being fetched as a Collection?
I understand that you can access Response Headers when using the ‘REST API Request’ or ‘Xano Request’ but not from the Collections response.
I want to be able to handle a Status Code: 206 Partial Content response. In this scenario, the data should be returned so it can be accessible as a Collection, and downstream workflow actions should be handled with the context of the status code.
It would be ideal to be able to manage all status codes, rather than forcing a >400 code.
Hey @MichaelLovell 
I’m not sure I understand you question. Can you illustrate what you are trying to achieve?
The catalyst to this thread is sooner or later people run into a challenge where they try to restrict or display data using front end logic that would be better served by handling the logic in the backend.
But specifically, let me illustrate.
The collection in this workflow throws an error based on backend logic. For example purposes only, I’m throwing a 409 Conflict status code.
Because the response error code is >400 it triggers the ‘On error’ workflow. Here we can access the full response headers and then route the error based on the specific status code.
But we might want the response to succeed to continue processing downstream actions, including handling that status code by showing a dialog, and still return the data in the Collection. For example purposes only, in the next images I’m throwing a 206 Partial Content status code.
The response headers can’t be accessed from the workflow action results. That’s okay.
This is promising. The collection itself has config property. But it doesn’t contain the status and headers is empty! Why?
The silly workaround at the moment is this. I configure a global workflow to make a ‘Request’ rather than a ‘Fetch collection’. I now have full access to the response incl. status code etc. But then I need to also create a variable to store the response data. I need to configure this for each ‘pseudo collection’ where I handle a response that succeeds with a response other than a standard 200.
My naivety seems to think my convoluted workaround could be resolved by exposing additional response properties in the Collection. 
Thanks for all the examples!
The team is thinking about having more options after an error occurs. This sould be prioritized around September. We’ll keep you updated on that!
