question

I agree. At least a way to get the raw output that the device is seeing.

Hey guys I use runscope for this ( https://www.runscope.com/) Just plugin your endpoint and use runscope's url at your dev application endpoint. It works like a charm. You will be able to see Header/Body info from the request as well as your Response.

Jeff, ahomes0 Thank you very much for your feedback, Our current debugging story includes, a message from the Echo Device as mention above, as well as, a publish GUI card in the companion application with some details about what went wrong, we are aware of the need for better debugging and is improving this story as we progress in making the Echo SDK better. Again, thank you very much for the feedback and please let us know how the GUI cards are working for you from a debugging standpoint.

Hi, of course. Here's some follow-up information. In one problem example, I did not capitalize the "s" in "Simple" for a card response. Thankfully I saw this right away and corrected it, but the feedback I received from the Echo was quite limited, and I can imagine it may not always be so simple to debug. The spoken text I got back from the Echo was "There was a problem communicating with the requested application," and the card was "Unexpected Communication Issue - There was a problem communicating with the requested application." Really, these could mean anything. Did my application return a 500 error? Was Amazon able to reach my API endpoint? Did my application send a malformed response? Did the user request an intent that caused some odd problem? In the case of my "simple" versus "Simple" issue, a card that showed something like "Unexpected card type "simple" was specified. Valid card types are "Simple," "Standard," "Media"" Another card I've received is "Protocol Violation." It would help to know what, exactly, my application sent back that Amazon didn't expect. Protocol Violation The application response did conform to the specification. Please ensure that you are using the latest client library and that your responses comply with the Application Service Interface. Could be followed up by some information on what lines or strings in the JSON response were unexpected. While the suggestion by @Noel is something all of us should be capable of doing, it might still be helpful to include HTTP headers and bodies in the debugging cards by default anyway (or perhaps by sending a "debug:true" variable in the response).

Oh, and just really quickly, to more directly answer how the cards are helping with my debugging - the answer is they aren't providing anymore information than telling me an error occurred. Something more is needed for sure. :)

aholmes0, This is very very valuable feedback, those are great examples of ways we can improve the developer experience, Thank you very much for this feedback, we will incorporate your feedback as we progress on making improvements to the Echo SDK. Stay tuned!