The V2 Tasks has an enum for type (instead of string). Is that the change going forward?

API Q&A
1

The Company added a Task type a few years ago called “Update” using the Keap web interface. In the V2 API, the type field is an enum, which conflicts with the idea that users can add types. Will type remain an enum going forward, or will it revert to string? I am unable to retrieve tasks for a user when any of their tasks contain a type that is not an enum member. There isn’t a graceful fallback for this condition. Example:

url: https://api.infusionsoft.com/crm/rest/v2/tasks?filter=user_id%3D%3D1
response:
{
    "code": 400,
    "message": "No enum constant com.infusionsoft.calendar.enums.TaskType.Update",
    "status": "Bad Request",
    "details": [
        {
            "domain": "task",
            "resource": "GET /rest/v2/tasks"
        }
    ]
}

Additionally, is there a filter to select only incomplete tasks like the v1 API has?
Thanks in advance,
John

2

With the endpoint you provided, I think you want to use GET for your request method.

My test using GET worked w/o issue.

3

As indicated in the server response sample, I used GET.

The larger issue here is that when the API retrieves Tasks data from the db (on Keap’s end) and it does not conform to the enum called “type”, the endpoint fails. You may have tested it, but did any of your tasks have a type other than one of the following? “EMAIL” “CALL” “APPOINTMENT” “FAX” “LETTER” “OTHER”

Admin users are allowed to add new “types” in the Infusionsoft web interface. This makes either forcing “type” into an enum (on Keap’s end) contraindicated, or being able to add new “types” is contraindicated.

4

I was honestly confused by the word UPDATE, and you’re correct. UPDATE is NOT included on the ENUMs, and completely ignored.

When I ran my earlier test, None of the tasks I had setup in my sandbox were set for UPDATE.

When I created one task w/ the UPDATE action type, I got the same error immediately.

{
“code”: 400,
“message”: “No enum constant com.infusionsoft.calendar.enums.TaskType.UPDATE”,
“status”: “Bad Request”,
“details”: [
{
“domain”: “task”,
“resource”: “GET /rest/v2/tasks”
}
]
}

5

No worries. I’m wondering what the way forward is.

For now I have to support 2 APIs in my backend C# application and in some cases 2 sets of DTOs depending on the version of the API I use for each given method. So far, Tasks is the only method where I need to use v1.

6

Hi @JohnK_AZ,

I recommend that you raise a Support Ticket regarding this issue.

From what I am seeing in the documentation, in REST v1 it allows a String to be passed without any restriction. But in REST v2 they need to match the supplied Enum. Seems to me that whoever developed or tested the endpoint did not realise about the custom types.

Apparently, a whole load of new REST v2 endpoints should have been released by now. Maybe they have corrected that issue in that update.

7

I used Postman and the REST V2 API for the task, and got that error w/o passing any filter, and the error triggered immediately, so I would say it’s not patched in the V2 endpoints, and is currently a bug.

8

Oh, you are right. It gives a 500 error (server), instead of a 400 Bad Request / message when hitting it without any parameters.

9

I think you are right about it not being finished at this point. And Marion pointed out a 500 error that shouldn’t occur with no parameters. I will put in a ticket.

10

To clarify, I’m not getting a 500 error, I’m getting the 400 bad request still. The 400 error started immediately after I created a task w/ the action type of UPDATE.

11

Oh OK. That makes sense. I was referring to your comment about using Postman without a filter, which does give a 500:
https://api.infusionsoft.com/crm/rest/v2/tasks
{
“code”: 500,
“message”: “An unexpected error occurred”,
“status”: “Internal Server Error”,
“details”: [
{
“domain”: “task”,
“resource”: “GET /rest/v2/tasks”
}
]
}

I have tried to create 3 support tickets. Two a few days ago, and 1 again today. They don’t seem to register. View My Tickets shows nothing. I am going to call in.

12

That’s really weird. Using Postman w/o any filter just hitting the endpoint URL, I’m still getting the 400 Bad Request error.

13

I am using a Service Account Key for our 1st party integration. Maybe that would be the difference in API response?

14

I got a ticket in. I’ll post back with any resolution/info.

15

I’m using a SAK as well… hmmn.

This is the PHP code being rendered by Postman:

<?php

$curl = curl_init();

curl_setopt_array($curl, array(
  CURLOPT_URL => 'https://api.infusionsoft.com/crm/rest/v2/tasks',
  CURLOPT_RETURNTRANSFER => true,
  CURLOPT_ENCODING => '',
  CURLOPT_MAXREDIRS => 10,
  CURLOPT_TIMEOUT => 0,
  CURLOPT_FOLLOWLOCATION => true,
  CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
  CURLOPT_CUSTOMREQUEST => 'GET',
  CURLOPT_HTTPHEADER => array(
    'Authorization: Bearer ....,
    'Cookie: ....'
  ),
));

$response = curl_exec($curl);

curl_close($curl);
echo $response;
16

Bugs have been confirmed and this has been added to the Known Issues page. Current solution is to continue with v1 for this endpoint.

1 Like