Clio API: bulk actions not returning 303 status code

551 Views Asked by At

I'm not seeing a 303 response for bulk actions using latest v4 api for the activities endpoint.

From The API Documentation:

  1. Make a request to the action with an X-BULK header with the value true. The response will always be a 202 Accepted.

  2. Poll the URL provided in the Location header of the response. This URL is for the Bulk Actions endpoint.

  3. Once the action is complete, polling the URL will return a 303 See Other response.

  4. Download the response from URL in the Location header of the 303 See other response.

Here's what I'm doing:

I issue the initial request to the activities endpoint with the X-BULK header set to 'true'.

  • I receive a 202 Acceptedresponse with a Location header set to the polling url.

I begin polling the provided url from the Location header.

  • I receive a few 200 responses with the following data and headers:

Data:

{"data":{"id":26952539,"etag":"\\"434fa52f83b8e0bb72677f60b8297866\\""}}

Headers:

{ 
  'content-type': 'application/json; charset=utf-8',
  'transfer-encoding': 'chunked',
  connection: 'close',
  vary: 'Accept-Encoding',
  status: '200 OK',
  'last-modified': 'Sat, 02 Dec 2017 22:17:13 GMT',
  'x-ratelimit-limit': '50',
  'x-ratelimit-reset': '1512253080',
  'x-ratelimit-remaining': '45',
  'x-request-id': '4674a764-c417-448c-af09-c6dae1cabe15',
  etag: '"434fa52f83b8e0bb72677f60b8297866"',
  'x-frame-options': 'SAMEORIGIN',
  'cache-control': 'no-cache, private, no-store',
  'x-xss-protection': '1; mode=block',
  'x-api-version': '4.0.5',
  'x-content-type-options': 'nosniff',
  date: 'Sat, 02 Dec 2017 22:17:13 GMT',
  'set-cookie':
  [ 'XSRF-TOKEN=oQqTKV8XKRm9oiMuY1OFZ6qleZyRyvtcs9v52%2FWyeiVXxvVszHLiXsQkWelnUHs3ErSsH64ctIpehxErulAWHg%3D%3D; path=/; secure',
    '_session_id=7babc5f94bc48ecd5d18d4b40c17d6ca; path=/; secure; HttpOnly' ],
  server: 'nginx',
  'strict-transport-security': 'max-age=31536000; includeSubdomains' 
} 

However a 303 never comes. After a few of the above 200s I get another 200 with the payload:

Data:

{
  "data": [
    {
      "data": [ {id: 1...}, {id: 2...}, {id: 3...}, ... ],
      "status": 200
    }
  ],
  "status": "completed",
  "requested": 46,
  "performed": 46
}

Headers:

{ 
  'x-amz-id-2': '1uiNt20Vd/X74JxKZKrt/hah7aof8xfhZlt7fhlDt8b3G2nA47Y8ZDaohb2drSF8ErniirRK2Es=',
  'x-amz-request-id': '2B29557952779E29',
  date: 'Sat, 02 Dec 2017 22:17:15 GMT',
  'last-modified': 'Sat, 02 Dec 2017 22:17:14 GMT',
  'x-amz-expiration': 'expiry-date="Wed, 06 Dec 2017 00:00:00 GMT", rule-id="Expiration rule (auto-generated)"',
  etag: '"58e33e4eced83d145bf6dec9f72b97be-1"',
  'x-amz-server-side-encryption': 'AES256',
  'content-encoding': 'utf-8',
  'x-amz-version-id': '2Ou7F__59Pz8WKOKZwFg_fOuhQjD5ro0',
  'content-disposition': 'attachment; filename="activities 20171202.json";',
  'accept-ranges': 'bytes',
  'content-type': 'application/json',
  'content-length': '9593',
  server: 'AmazonS3',
  connection: 'close' 
} 

It appears I can work around this sufficiently by testing for status === 'completed', or even checking for the presence of the content-disposition header.

Am I doing something wrong that prohibits a 303 response, or are there semantics for the activities endpoint that I'm ignoring?

Is it sufficient to test for status === 'completed' to work around this issue?

Note: I am passing the Authorization header for every request, which includes the access token.

Thanks!

2

There are 2 best solutions below

0
On BEST ANSWER

This is a known bug with the Clio API-V4. The best solution at this time is:

testing the payload of the 200 for status === 'completed'

We are working on resolving the lack of 303 response. In the meantime we will update the documentation.

0
On

Here's a workaround I've been using with very good results:

  1. Use the ignore_redirect parameter when querying a bulk action status:

    /api/v4/bulk_actions/?ignore_redirect=true

  2. Use the ?fields=Response_Url parameter to get the actual URL of the response.

  3. Download the result from the Response_Url property.

I've never had these methods fail.