Characters_reserved_per_media is still 24 when it now should be 0

[SaschaNaz]

The update today does not reserve additional space to upload media. characters_reserved_per_media should be 0 then.

[andypiper]

Thanks for the pointer, I’ll check in with the engineers on this.

[andypiper]

I think the (interim) answer here is that it depends. If you are using the media/upload endpoint the media should “disappear” into the metadata, but if you are using a legacy media posting API this still applies. I’ll work with the platform team to see how we can clarify this.

[thriolsson]

It would be nice if it was clearly stated in the documentation how to count characters. The page https://dev.twitter.com/overview/api/counting-characters does not mention anything about “characters_reserved_per_media”.
The only place this is mentioned is in the deprecated https://dev.twitter.com/rest/reference/post/statuses/update_with_media

This fact is mentioned here (last year), where you have responded that you will look into it:

Can you update the docs to discuss the fact that media subtracts from the character count?

Hey guys, nice job on the excellent docs for the REST API. As you know, attaching media to a tweet reduces the available character count by 24. This constant is available by querying help/configuration endpoint under the field characters_reserved_per_media. Can you add a note of this to the documentation page that discusses uploading media? (https://dev.twitter.com/rest/public/uploading-media). Currently the only page in the docs that references this crucial fact is the old statuses/update_…

[andypiper]

We’ll definitely be updating the documentation across the board as the rest of the extended-tweet change rolls out. Until then, the canonical information on the new Tweet format is the single page on the changes.

Assuming you use the media upload endpoint and attach media Ids to your created Tweet, the URL space reserved for the media will no longer be counted in the 140. If you paste other URLs into the text of your Tweet, it will be counted. In fact, a media item does still take up 24 characters (a tokenised t.co link with a leading space), but the display index will essentially cancel this out.

We apologise for any confusion during this interim period. We are taking your comments on-board and will work to improve this situation shortly.

[thriolsson]

So what you are saying is that characters_reserved_per_media should never be used?

Another thing I have found to be confusing is that the response from statuses/update differs depending only on the length of the message. If the message with one image and the text is 0-116 characters, you will find a element under , but if the message is 116-140 characters, there will be no elements, but instead an.item in the section.

[jfriedl]

Any update on this? As of today, characters_reserved_per_media is still returning 24.

[jfriedl]

To be clear, I’m asking specifically about if/when characters_reserved_per_media should be used, including with the “statuses/update_with_media” endpoint.

[jfriedl]

@andypiper or any Twitter engineer, can we please have an update on this. characters_reserved_per_media is still returning 24 as of today (Dec 19, 2016). For what endpoints do we ignore characters_reserved_per_media, and for what endpoints does it apply?

Thanks.

[andypiper]

You should not use the statuses/update_with_media endpoint as it is deprecated, and does not support the attachment_url method of attaching media which would cause it not to be counted. If you insist on continuing to use that legacy method, be aware that the characters_reserved_per_media should still be taken into account.

In other cases, specifically the two-step media/upload and statuses/update process of posting media, this can simply be ignored as a legacy value.

[jfriedl]

Thank you for the reply, Andy. My use of the old endpoint is not out of a stubborn instance, but because that’s the only endpoint that was available when the app was created, and I’d prefer not to retool if it’s not required, especially since the two-step approach does not fit well with the parent app my work fits into. But I understand from your reply that the retooling is necessary if I want to remove the character limit.

[jfriedl]

By the way, Andy, I think there’s a mistake in the docs… shouldn’t the “Resource URL” given at the top of https://dev.twitter.com/rest/reference/post/media/upload be “https://upload.twitter.com/1.1/media/upload.json” instead of referring to “1.1/update.json”?

[andypiper]

Thanks for spotting that.

[jfriedl]

Is “photo_size_limit” another of the configuration.json items we’re now supposed to ignore?
Some docs are saying the limit is 5MB, but the software is explicitly saying (via photo_size_limit) that it’s 3MB (3145728 bytes).

I built my app to trust and enforce “photo_size_limit” because that is the entire point of having “photo_size_limit” in he API in the first place, no?

If we’re not supposed to trust “photo_size_limit”, why is it still being returned? Why is its deprecation not documented? (Or is it and I’m just not finding it?)

For that matter, why is the deprecation of “characters_reserved_per_media” not mentioned on https://dev.twitter.com/rest/reference/get/help/configuration?

Keeping docs up to date is a PITA, I know, but probably less so than responding over and over to people like me

[jfriedl]

Is the report of a mistake correct, or is it not a mistake? Three weeks later, the page remains unchanged…

[andypiper]

This is still not updated - I was on the road for a couple.of weeks and we cannot always update things right away.

[jfriedl]

Okay, thanks. When you get a moment, some direction on “photo_size_limit” would be appreciated.