Legacy Dev Forum Posts

 View Only

Sign Up

Analytics Conversation API query failing in SDKs due to dispositionName

  • 1.  Analytics Conversation API query failing in SDKs due to dispositionName

    Posted 06-05-2025 18:13

    greg.patrick | 2018-03-16 22:49:05 UTC | #1

    I'm using the Ruby SDK but I checked the (generated) source code of the Java and python SDKs and it looks like they have this same problem.

    1. Use a Campaign to make outgoing calls.
    2. Use the API SDK to make an /api/v2/analytics/conversations/details/query query.
    3. Query fails with an ArgumentError, e.g.

    ArgumentError: invalid value for 'dispositionname', must be one of ["disconnect", "person", "busy", "machine", "noanswer", "fax", "sit"]. from /Users/greg/.rvm/gems/ruby-2.3.1@varsitytutors/gems/purecloudplatformclientv2-27.0.0/lib/purecloudplatformclientv2/models/analyticssession.rb:924:in `disposition_name='

    Using the only API Explorer instead, I can see that the problem is that dispositionName is not a single word as expected (as per the error message above).

    E.g. this is what is actually being returned:

    "dispositionName": "disposition.classification.callable.person"

    I.e. the code is expecting "person", not "disposition.classification.callable.person"


    tim.smith | 2018-03-19 15:43:31 UTC | #2

    The generated SDKs have incorrect values because the API is documented incorrectly. I've opened API-3249 to have the API annotated with the correct values for that property.


    greg.patrick | 2018-03-19 18:32:00 UTC | #3

    tim.smith, post:2, topic:2631, full:true
    The generated SDKs have incorrect values because the API is documented incorrectly. I’ve opened API-3249 to have the API annotated with the correct values for that property.

    Do you know what we might expect for a timeframe when this might be resolved? Since the API call fails, we can't get the information we want for Campaign calls (at least via that API call)


    tim.smith | 2018-03-19 19:01:00 UTC | #4

    It will probably be 1-2 weeks before the change makes it to production and the SDKs pick it up.

    In the meantime, if you want to customize the current version of the SDK to fix this locally, you would need to remove the checks for allowable_values on the disposition_name property here and here. The official fix for this issue is to remove the allowable values annotation from the API since the values for the property aren't static; having an enum for this property isn't a correct definition based on the data it contains. This will cause the SDK to no longer validate the value of the disposition_name property.


    system | 2018-04-19 19:13:30 UTC | #5

    This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.


    This post was migrated from the old Developer Forum.

    ref: 2631