Request and response inconsistencies


If I fetch a list of surveys from the API (/survey), I’ll get a lot of objects which has type ‘Standard Survey’. If I try to create a survey with that type, I’ll get a 400 – Bad request error. I can, however, create a survey with the type ‘survey’ – this then returns an object with an empty type field.

Is there any chance the two will be aligned in this or future versions of the API? It makes it horribly difficult to consume the API.

In the meantime, is there any documentation as to what values are acceptable for the different fields? 

Community Admin answered

    Hi there,

    I the return for the survey object changed a bit with the v5 API. I can definitely pass along this feedback to our development team.

    As far as possible values you can find our API documentation here:

    Under each version you there is documentation for each object; these will have all possible values for each object.

    The Return Formats and Fields should help you better understand what is returned.

    I hope this helps!

    The SurveyGizmo Team

    Community Admin commented
      • That would be great. If I could make a few recommendations to make the API a little more RESTful and a lot easier to work with:
        – An object should only ever have one shape. If a survey has a field “team”, which is an object with id and name, it should be so everywhere. Today, you’ll create it with a string containing the id, get it as an object when you fetch just the survey, and get just the id when fetching a list. This means a strongly typed language need three different classes to model the interaction as well as code to translate between them – a lot of work to develop and maintain.
        – Strings with special significance should be constant, e.g. the example above. The significance of the value rests with the object, not the action performed on it.
        – Use the actual HTTP methods (GET/POST/PUT/DELETE). If not possible due to a need to support legacy clients or proxies, at least use POST for post and put actions. That way you’ll also avoid hitting any kind of url limits and data could be json encoded as the response is.

        If I understand you correctly, I can trust the documentation for the requests ( I ask because I cannot trust the documentations on return values ( as per the example above.

      • Thanks for this feedback! As far as the documentation. I submitted a bug fix with the development team to change the return back to Survey.

        As far as the documentation we do our very best to keep this up to date! Do let us know if you run into further inconsistencies.

        The SurveyGizmo Team



      Question stats

      • Active
      • Views9678 times
      • Answers1 answer
      • Followers1 follower