Protocol Error when requesting campaign reach



We’re getting an error when calling this endpoint -

… e.g. -

Returns -

{“The remote server returned an error: (400) Bad Request.”}

… and …

Status = ProtocolError

Anyone seen anything like this before?

Any tips greatly appreciated.


Hi @niki_wiles! Maybe start_time and end_time must align to midnight in the account’s timezone?.. Take a look at the second paragraph under the title “Specifying Datetime Values With Timezone” - this is about the endpoints that use the granularity parameter, but maybe this applies to your endpoint as well… I don’t know; just give it a try.


Hi @majoritasdev

Thanks, that looked really promising. I gave it a shot, but this -

… seems to produce the same problem :disappointed:


@niki_wiles: what is your account timezone? If it’s not UTC, then those dates are not midnights. They should be midnights in your account’s timezone, expressed in UTC. For example: if my account timezone is “Athens, Greece” then start_time should be 2016-01-05T22:00:00Z and end_time should be 2016-01-06T22:00:00Z, since Athens, Greece is in UTC+2 hours.


Thanks again @majoritasdev. The account timezone is set to GMT, so I guess that would be the same as UTC.


Yes. I see. Then, I don’t know.

Twitter staff?


@niki_wiles There’s nothing obviously wrong with you request in terms of usage. Additionally, I’m able to successfully execute this request with twurl (see below):

twurl -H "/0/stats/accounts/18ce53ur22q/reach/campaigns?start_time=2016-01-06T00:00:00Z&end_time=2016-01-06T23:59:59Z&campaign_ids=3x9tp" 

  "errors": [
      "code": "FEATURE_NOT_AVAILABLE",
      "message": "The account does not have the feature REACH_AND_FREQUENCY_ANALYTICS",
      "parameter": ""
  "request": {
    "params": {
      "campaign_ids": [
      "start_time": "2016-01-06T00:00:00Z",
      "end_time": "2016-01-06T23:59:59Z",
      "account_id": "18ce53ur22q"

Note that the response shows a different error because this account doesn’t have access to this white-listed feature yet, but the request is successful (eg. not a malformed request as your seeing). The fact that this works in twurl but not in your implementation would seem to indicate that the issue is not an API issue or a usage issue but something in your current implementation.

We’re limited on how much we can troubleshoot within your own implementation, but can you share more technical details about how you’ve implemented making this request?


@niki_wiles: I guess that if you have access to the feature REACH_AND_FREQUENCY_ANALYTICS (and not only for this one) it would appear in the response to this call GET accounts/:account_id/features, even though this feature is not documented. So you can check that.


Very useful! It seems that I don’t have access to this feature - thanks for the tip. I actually had no idea that there were individual features that you had to be white listed for separately.

  "results": {
    "request": {
      "params": {
        "account_id": "18ce53ur22q"
    "data_type": "features",
    "data": [


@brandonmblack - thanks for this. Based on the tip by @majoritasdev it looks like I’m not actually whitelisted for this feature, although it’s strange that I didn’t get a similar error to you.

I can’t see any mention of REACH_AND_FREQUENCY_ANALYTICS in the docs - how do you know which parts of the API require white listing? So I guess it’s just a case of reaching out to our contact @ Twitter and asking to have that specific property white listed on our account?


@niki_wiles: :thumbsup:

@brandonmblack: it would be very helpful if the call to GET accounts/:account_id/features would return all possible features with true / false values depending on the access.


@niki_wiles only features that aren’t yet generally available show up in GET accounts/:account_id/features. Once a feature has been made available to all API consumers, there’s no longer a need to differentiate access.

Often when we release these features in beta or pre-beta stages they’re only released to a select subset of developers we know could benefit from them and we don’t always widely advertise the feature’s existence (this is why there’s intentionally no complete feature list via GET /features or anywhere else).

When we do announce new features or we’re soliciting for beta participants we always make sure to communicate whether white list access is required to use the feature in our announcements via forums, recent changes, docs and the @adsapi Twitter handle.

If you’re interested in gaining access to a feature that currently has limited availability, you just need to reach out to your partner manager (Jackie, Jill or Michael) and they can follow up with you on it.