Corresponding line item (and higher level) data not retrieved where a promoted tweet is found

[John_Developer]

Hi,

We are using both the management and analytics endpoints and have found a situation where a promoted tweet is returned to us (via both management and analytics), but that its parent line item is not. Although it is occurring for both, our investigation of this is largely centred on the management calls.

Are there any circumstances in which this is a valid thing to happen?

We have tried as far as possible to rule out misuse at our end. E.g. In all cases we are fully paginating through all of the data for all entities. We have also considered the possibility that the line item is deleted whereas the promoted tweet is not (not sure whether this is possible), but we see the same behaviour even when retrieving all entities, including deleted ones.

Most of the other options (which we’re not using) in the data management API calls appear to be for scoping down the returned data, so it’s difficult to see how we could change our request such that more data would come back.

If necessary we have a specific example of this that we can provide - please let us know if you would like to see that, and if so whether we should put details here or elsewhere.

Many thanks.

[juanshishido]

Thanks for the question, @John_Developer. Having a specific example would definitely help us. Please provide example requests and responses using twurl. I mostly want to see an example promoted_tweets entity.

[John_Developer]

Hi again, apologies but we are currently having problems using Twurl. This could be misuse from us, but we are getting the “Usage…” message for most calls we make. We have previously used Twurl with some level of success.

Instead we have successfully reproduced the issue via Postman. However we do not wish to paste requests and responses containing client data in a public forum. Is there any chance we can send you this via some other private channel?

Thanks in advance.

[juanshishido]

Thanks, @John_Developer. The reason I was asking for specific example requests and responses is that it’s unclear what the issue is. I can try to guess, but I want to limit confusion. Let me try asking a question and have you confirm.

1. When you use the GET accounts/:account_id/promoted_tweets endpoint, sometimes the line item associated with it is not found when you make a GET accounts/:account_id/line_items request. Is that right?
   • If so, please provide at least the promoted_tweets ID.

Once we sort this out, then we can talk about analytics, but let’s keep that separate for now.

---

For reference, please see our Guidelines for Reporting Issues. It’s ultimately up to you whether you provide example requests and responses, but it makes it more difficult without it.

[John_Developer]

Yes, that is correct. The line item ID returned with a promoted tweet is not found when separately requesting line items.

We are happy to provide just the IDs of an example of where this is happening:

Promoted tweet ID: yndgl
Line item ID: 644iz

We have read your attached guidelines on what is safe to post here and although our responses should only contain data you’ve listed as “safe”, we are not comfortable in particular with account IDs or app IDs being posted here. If you require more information than the two IDs above, please indicate a private channel via which we can send this, thanks.

[juanshishido]

Thanks for providing these details. The reason this line item is not returned in the GET accounts/:account_id/line_items request is that the line item is in a draft state—"entity_status": "DRAFT". When making requests for draft line items (or campaigns), please specify draft_only=true in the request.

[John_Developer]

Ok, thank you for the explanation. We will review what our connector is doing with regard to draft campaigns subject to the constraints of the API.

[John_Developer]

We have discussed this further at our end, and we would like to check our understanding, as it seems that normal use of the management calls (without use of draft_only) leads to inconsistencies in the data we are retrieving. Specifically, why is it the case that the draft_only flag is available for campaigns and line items, but not promoted tweets (or promoted accounts)?

The following page (admittedly from a couple of years ago) indicates that draft_only is accepted for promoted tweets and promoted accounts amongst other things:

Announcement: Draft campaigns now accessible via the API

Today we are announcing the ability to view, edit, and delete draft campaigns via the API. With this change, we’re introducing the boolean draft_only parameter as well as the entity_status attribute in our response objects for campaigns and line items. In addition, it will be possible to access entities, such as promoted tweets, that are part of a draft campaign. Note that it will not be possible to create or activate draft campaigns via the API. The draft_only parameter will be accepted when …

But the documentation and the example we have given here suggests not.

As it stands, this means that we cannot directly avoid getting promoted tweets under draft campaigns, despite their parent entities being excluded by default (draft_only=false). Ideally we’d like to just exclude draft campaigns and their child entities altogether. To resolve this at our end, we would need to make separate calls at campaign / line item level to identify draft campaigns and associated line items, and then cross-check and discard unwanted promoted tweets as appropriate.

Whilst we can certainly do this, there is some level of development and testing effort, and this could have performance or rate-limiting implications given the additional API calls required.

We’d therefore like to check with you first to get an explanation of the inconsistency between the above announcement and the documentation. If it is true that draft_only is not supported for promoted tweets and promoted accounts, is there any intention/possibility of providing it? Thanks.

[juanshishido]

Good follow up, @John_Developer.

why is it the case that the draft_only flag is available for campaigns and line items, but not promoted tweets (or promoted accounts)?

In version 3, we announced that we were removing the draft_only parameter from several endpoints (see the “Removed” section). This is because those entities can never be in a draft state.

As it stands, this means that we cannot directly avoid getting promoted tweets under draft campaigns, despite their parent entities being excluded by default (draft_only=false). Ideally we’d like to just exclude draft campaigns and their child entities altogether.

Thanks for this feedback. Could you let us know what your specific use case is here? For example, are you displaying promoted_tweets on a page and want to exclude ones under draft campaigns? (If so, why?) Or are you pulling stats for promoted_tweets and want to exclude those because you know there would be no data? We’d like to understand the flow.

[John_Developer]

Just parking your questions on the use case for a moment, I think the real issue here is confusion on the difference between a “draft item”, and an “item which is under a draft campaign”.

You’ve pointed out that “draft_only” has been dropped for promoted tweets and promoted accounts because there is no such thing as a “draft promoted tweet” or a “draft promoted account”. From this, we infer that there does exist such a thing as a “draft line item”, and this appears to match up with the documentation.

However the documentation for the line items call says the following for the “draft_only” flag:

Scope the response to just line items under draft campaigns.

I.e. It does not say “Scope the response to just draft line items.” From this I would conclude that either:

• Draft line items are synonymous with line items under draft campaigns (i.e. a draft line item cannot exist under an active campaign).
• Setting draft_only=true will not retrieve draft line items under active campaigns.

If (1) is true, this goes against what we’ve said above – the assumption is that line items can have a status of draft independently of the parent campaign. It would also raise the question of why draft_only would be retained for line items but not for promoted tweets, as they would behave the same in the context of draft campaigns.

If (2) is true, this would seem very misleading that you can set the flag to true but not receive all draft line items.

If you are able to clarify this, it would be much appreciated.

Returning to your questions, our use case is that we want to retrieve and report on all management and analytics data at campaign, line item and promoted tweet level. We are imagining that this data would be consistent, e.g. if we retrieve a promoted tweet, we’d expect its parent entities to also be retrieved in the corresponding calls. For the example we gave, we have retrieved non-zero analytics data for that promoted tweet despite it being under a draft line item. We would not expect to be obtaining analytics data for draft items, but given the above point on how draft items work, we may have misunderstood this.

[system]

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

[juanshishido]

Thanks for the detailed reply, @John_Developer. You’re correct. The description of the draft_only parameter should say. “Scope the response to just draft line items.” We will update that.