Problem with audience manager trying to create an audience through API

[dodnert]

Thanks, @brandonmblack. I have just two things I’d like to point out in response.

1. There is no documentation of the X-TON-Expires header anywhere on dev.twitter.com that I could find. This needs to be fixed.

2. On the TON API overview page, you will find the sentence “For Tailored Audiences, please use the bucket name ta_partner.” Would it be so difficult to add one more sentence that reads “For Tailored Audience uploads, please make sure that the X-TON-Expires header is defined with the date set to ???.”

[brandonmblack]

@dodnert done.

https://dev.twitter.com/rest/ton

[dodnert]

@brandonmblack - Cool!

BTW, is there documentation anywhere about the date string syntax that is acceptable in this X-header?

[liviutudor]

@dodnert the date string is a standard http date header
@brandonmblack thanks for updating the docco’s

[brandonmblack]

@dodnert @liviutudor’s comment is correct. We use the HTTP standard for representing date times in headers. You can read more about that here.

Here’s the relevant section:

HTTP applications have historically allowed three different formats for
the representation of date/time stamps:

Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C’s asctime() format

The first format is preferred as an Internet standard and represents
a fixed-length subset of that defined by RFC 1123 [8] (an update to
RFC 822 [9]). The second format is in common use, but is based on the
obsolete RFC 850 [12] date format and lacks a four-digit year.
HTTP/1.1 clients and servers that parse the date value MUST accept
all three formats (for compatibility with HTTP/1.0), though they MUST
only generate the RFC 1123 format for representing HTTP-date values
in header fields. See section 19.3 for further information.

Additionally, make sure you note that the RFC also requires all times always be in GMT / UTC:

All HTTP date/time stamps MUST be represented in Greenwich Mean Time
(GMT), without exception. For the purposes of HTTP, GMT is exactly
equal to UTC (Coordinated Universal Time).

[liviutudor]

OK so having gotten past the issue with TON I am still encountering issues now with the Tailored Audiences API – the dreaded 403:

HTTP/1.1 403 Forbidden [content-disposition: attachment; filename=json.json, content-type: application/json;charset=utf-8, date: Tue, 19 May 2015 20:23:31 GMT, server: tsa_a, set-cookie: guest_id=v1%3A143206701154609507; Domain=.twitter.com; Path=/; Expires=Thu, 18-May-2017 20:23:31 UTC, strict-transport-security: max-age=631138519, x-access-level: read-write, x-connection-hash: fd85961944b8bd7cecaf2977de6dd1fa, x-content-type-options: nosniff, x-frame-options: SAMEORIGIN, x-response-time: 23, x-runtime: 0.01229, x-transaction: 36c9b81e714421b7, x-xss-protection: 1; mode=block

As I understand this is not an issue with OAuth but rather with having access to this API?

[liviutudor]

@brandonmblack are you aware of any special requirements (headers etc) with the Tailored Audiences API?
The error response clearly states this as I get:

UNAUTHORIZED_CLIENT_APPLICATION / The client application making this request does not have access to this API

[brandonmblack]

@liviutudor looks like this might be another instance of your app not being setup correctly. Apologies this wasn’t handled correctly in the first attempt. Can you give it another try?

[liviutudor]

@brandonmblack Thanks for promptly jumping on this! I can confirm now I was able to create, delete, retrieve an audience now.
Testing next uploading changes to it – my guess is with TON and TA working this should be fine too but I will post here an update to confirm.

[liviutudor]

@brandonmblack OK so I am getting a 401 when POST-ing an audience change which suggests an OAuth issue. However, the same code used for all the other POST/GET blocks applies so I’m not entirely sure why that could happen.
Are there any particulars about POST accounts/:account_id/tailored_audience_changes ? (headers or parameters that are needed but not supplied in the docco?
If it helps diagnozing this, the audience details used in last test:

id=saqt
name=testing_audience_IhcldTpotjCMuCWDVQxEVQ8bNReoUHCDOfkBB9ncTQ

(I’ve deleted the audience in the meanwhile btw)

[liviutudor]

Update here – found another problem with the docco: for making changes to the audiences, there is a input_file_path parameter in the URL, which is a path from (previously) uploaded to TON. All the examples on that page suggest using the value from TON unencoded – e.g. /1.1/ton/data/ta_partner/3wyo1gwuqF7_Lhr (see https://dev.twitter.com/ads/reference/post/accounts/%3Aaccount_id/tailored_audience_change) however doing so fails with a 401 as the parameter when “unpacked” on the other side gets mangled. Instead, this parameter needs to be URL-encoded (and this has an effect on the OAuth headers). Probably need to update the docco to reflect this.

I can confirm though that create / make changes / delete / retrieve audiences works now on my end. (We haven’t implemented any of the other operations so might start a separate thread at the time if we find issues with it.)

Thank you so much for your help with this, @brandonmblack !

[brandonmblack]

@liviutudor glad I could help and glad to see you up and running.

[pykler]

@brandonmblack actually the initial post, if the X-Content-Length is too small (<< 8MB, e.g. 1KB) the initial post fails so you will not be able to do a multi part upload for small files. Same logic that is in the TON upload script needs to be kept.

[pykler]

There is also two headers returned from the first response that perhaps should be added to the documentation. (I have also left the values I received for those headers in there).

‘x-ton-max-chunk-size’: ‘67108864’,
‘x-ton-min-chunk-size’: ‘1048576’,

[pykler]

Another undocumented gotcha. The CHUNKSIZE has to be consistent … twitter is expecting the next chunks (except for the last one) to be of the same size. I was uploading my content row by row and stopping around the chunksize and that doesn’t work. So beware of that.

[pykler]

https://dev.twitter.com/rest/ton

Finally, the docs for https://dev.twitter.com/rest/ton/resumable are not accurate. The final 201 response does not have a location header!

[liviutudor]

@pykler Thanks for all the suggestions on that. I have actually created a separate thread here TON api multi-chunk upload errors HTTP/400 for the TON upload side of thinks.

As it happens I’m actually following all of those things you mentioned so not sure what is causing this.

Thanks again,

[Jhon_Pierre]

I have my app, and I am getting the same 403 error, How could I add the correct permission to access/use the TON API???
What I need to set on my app?

[liviutudor]

Hi Jhon,

In my case was nothing to do with my app itself but rather with the configuration on the Twitter side.

[Jhon_Pierre]

Which configuration u did? could u explainme a little more, maybe I need to do the same.