tumblr / docs Goto Github PK

It appears that the exclude_trail_items reblog parameter can only be used when reblogging a post directly, and not when editing an existing reblog. Is this intentional, and/or can it be changed?

I'm trying to build a feature which allows users to "trim" all but the last trail item from a post, since this is an oft-requested feature from roleplayers. Currently they enjoy "trimming" and adding content at the same time via a hack to the legacy post editor (where it works), but I'm trying to make something more robust which simply allows deleting trail items after the content has been added. It would be a lot more work to have to instead build a new reblog interface for these users, so being able to apply exclude_trail_items to existing reblogs would be very helpful.

I'm opening this issue here since the documentation for editing a post states:

For editing a post, all of the request parameters from the NPF Post Creation route are expected (depending on if it's an original post or reblog), along with the Post's ID in the query path.

But this is evidently not true, since reblog-specific parameters are completely ignored.

I'm definitely not complaining that reblogs can be edited without providing parent_tumblelog_uuid, parent_post_id, or reblog_key again, though; if allowing exclude_trail_items to be accepted by an existing post would mean also requiring the reblog-specific parameters, I wouldn't accept the trade-off.

I'm trying to gather user likes via the New Web Platform's tumblr.apiFetch() method. Supplying only the resource ('/v2/user/likes') and looping using the response's response.links.next.href value works imperfectly, so I tried specifying queryParams with the same values that the web client does. However, pulling queryParams from the response's link.next object does not work as expected.

(async () => {
  const resource = '/v2/user/likes';
  let queryParams = {
    'fields[blogs]': 'name,avatar,title,url,is_adult,?is_member,description_npf,uuid,can_be_followed,?followed,?advertiser_name,theme,?primary,?is_paywall_on,?paywall_access,?subscription_plan',
    limit: 21,
    reblog_info: true
  };
  
  while (queryParams) {
    const { response } = await window.tumblr.apiFetch(resource, { queryParams });
    // Do stuff with response.likedPosts
    queryParams = response.links?.next?.queryParams;
  }
})();

First request URL (with manually-specified queryParams): https://www.tumblr.com/api/v2/user/likes?fields%5Bblogs%5D=name%2Cavatar%2Ctitle%2Curl%2Cis_adult%2C%3Fis_member%2Cdescription_npf%2Cuuid%2Ccan_be_followed%2C%3Ffollowed%2C%3Fadvertiser_name%2Ctheme%2C%3Fprimary%2C%3Fis_paywall_on%2C%3Fpaywall_access%2C%3Fsubscription_plan&limit=21&reblog_info=true

First response links:

{
	"next": {
		"href": "/v2/user/likes?fields%5Bblogs%5D=name%2Cavatar%2Ctitle%2Curl%2Cis_adult%2C%3Fis_member%2Cdescription_npf%2Cuuid%2Ccan_be_followed%2C%3Ffollowed%2C%3Fadvertiser_name%2Ctheme%2C%3Fprimary%2C%3Fis_paywall_on%2C%3Fpaywall_access%2C%3Fsubscription_plan&limit=21&reblog_info=true&before=1624634022",
		"method": "GET",
		"queryParams": {
			"fields": {
				"blogs": "name,avatar,title,url,is_adult,?is_member,description_npf,uuid,can_be_followed,?followed,?advertiser_name,theme,?primary,?is_paywall_on,?paywall_access,?subscription_plan"
			},
			"limit": "21",
			"reblogInfo": "true",
			"before": "1624634022"
		}
	}
}

Second request URL (using API-supplied queryParams): https://www.tumblr.com/api/v2/user/likes?fields=%5Bobject%20Object%5D&limit=21&reblogInfo=true&before=1624634022

The apiFetch() queryParams documentation states "This will encode the params and append them to the request URL, so you don't need to do that yourself", but this is evidently not true when using API response queryParams, as any object-type value is not converted to an acceptable format and is instead directly converted to string - completely discarding any data within.

Tangientally related to #43 since the Tumblr API's custom format for object/array-type parameters is involved.

Currently the Tumblr API relies on OAuth 1.0a for authentication and flows, instead of the more modern OAuth 2.0 specification. With OAuth 2.0 now being eight years old, and OAuth 1.0a often being considered less secure, and has fewer supported features (for instance, it doesn't support non-web based flows), it'd be good to upgrade.

There's a good comparison found here, but I do understand this would likely be a significant amount of engineering work.

Some Image blocks have a colors object that does not match the "c[0-9]*" format. Ex.

"colors": {
    "04162a": 1352,
    "020f1d": 975,
    "7e4621": 850,
    "9a5229": 599,
    "4b2515": 499
}

From my quick tests, it appears to only happen rarely on some NSFW posts.

I have only started to see this within the past week.

Is this a bug in the API?
A new format of the colors object that is just starting to roll out?

Right now, the in-dash theme properties for a blog are not available to third-party clients. It would be really useful for rendering and customization purposes if those were available. For example, an app that referenced tumblr users could use the theme properties as an accent color for representing the user, like so:

Here are the theme properties i'm referring to:

"theme": {
  "header_full_width": 1280,
  "header_full_height": 875,
  "header_focus_width": 1149,
  "header_focus_height": 646,
  "avatar_shape": "square",
  "background_color": "#523960",
  "body_font": "Helvetica Neue",
  "header_bounds": "114,1214,760,65",
  "header_image": "https://static.tumblr.com/207557b65e8e5f2b678155a3ee16c5d9/zctqgvy/U3Eo7fy4b/tumblr_static_8g3m0bj4cv8kkkwks8w0okw04.jpg",
  "header_image_focused": "https://static.tumblr.com/207557b65e8e5f2b678155a3ee16c5d9/zctqgvy/tO0pnt0yl/tumblr_static_tumblr_static_8g3m0bj4cv8kkkwks8w0okw04_focused_v3.jpg",
  "header_image_scaled": "https://assets.tumblr.com/images/default_header/optica_pattern_10_focused_v3.png?_v=eafbfb1726b334d86841955ae7b9221c",
  "header_stretch": true,
  "link_color": "#f8f5d1",
  "show_avatar": true,
  "show_description": true,
  "show_header_image": true,
  "show_title": true,
  "title_color": "#935864",
  "title_font": "Square Serif",
  "title_font_weight": "bold"
},

(also, my header_image_scaled probably shouldn't be the default header image when I have a custom header image set? that seems bad lol)

Currently the API is documented just through the markdown specification, which means that each client needs to be written by hand. With a specification in a format such as OpenAPI, you'd be able to automatically generate clients, rather than maintaining them by hand.

I've started some work here, but ultimately this is a side-project to a side-project: https://gist.github.com/ThisIsMissEm/682a272fe1bef10c80ae497848cca06b

Hello, I’m not sure if this is the right place to ask this question!

I’m using Tumblr as sort of a timeline archive so I insert newer posts in between old posts and backdate them. The backdating works on the main blog’s page (the post automatically sorts itself accdg to the post date) but I’d like my posts within my blog’s tagged pages to appear chronologically as well. The /chrono url should work that way (i.e /tagged/2017/chrono), except it sorts my posts according to post id and not by post date.

My coding skills are limited, but I’d like to know if delving into the Tumblr API would allow me to retrieve published posts within a date range (i.e posts made within a specific year) and possibly sort them so it displays chronologically (by post date and not by post id), with the oldest post on top? I plan on adding a custom page still within Tumblr to display the posts (i.e /2017).

Would anyone know if this is possible, or is there a better fix for this issue? 😕

The send us your feedback link is broken.
It was probably intended to be a mailto: link, which might have been mangled by Markdown.

It always response "400 Bad Request"! I checked the post body format for hundreds of times, and can not see where is wrong. I can not post on your google group, and find where to submit a issue!

Here is my request body.

--TumblrBoundary
Content-Disposition: form-data; name="json"
Content-Type: application/json

{"content":[{"media":[{"height":101,"identifier":"file0","type":"image/jpeg","width":82}],"type":"image"}]}
--TumblrBoundary
Content-Disposition: form-data; name="file0"; filename="syl-logo.jpg"
Content-Type: image/jpeg

<binary image data>
--TumblrBoundary--
``

The examples for POST show a plaintext format:

POST https://api.tumblr.com/v2/user/filtered_content
filtered_content=something

POST https://api.tumblr.com/v2/user/filtered_content
filtered_content[0]=something&filtered_content[1]=technology

However, these requests return a 400 error.

After some trial and error, I determined that the requests that do work use a JSON format:

POST https://api.tumblr.com/v2/user/filtered_content
{"filtered_content":"something"}

POST https://api.tumblr.com/v2/user/filtered_content
{"filtered_content":["something","technology"]}

Hi. This is not a specific bug as such, but I was advised to post it here.

I have a theme I have rolled myself. It doesn't seem to work well with NPF post format. The goal is that all posts that have images should use the high res version where available.

I've worked with the api a fair bit and built different apps. But I think I want to leverage a full tumblr template in order to utilise likes, reblogs etc.

I looked at this recently: https://gist.github.com/cyle/ae03689903128a73bd174ba16d3ad195

Calling posts via js is nice

<script>
    var posts = new Array();
</script>
{block:Posts}
<script>
    posts[{PostId}] = {NPF};
</script>
{/block:Posts}
<div id="post-list"></div>

But it does not return any tag information, the post id seems to be the link to the post sometimes but not others.

The first four in this array have the correct ID to be able to build a link to the post, but the others do not work. See: https://imgur.com/a/oqlxb4k

So my question is.

Can I update my current theme to handle NPF posts better?
Can I just update to another NPF theme and format everything so it looks like my current theme? If so I want a really simple theme?
Can I use the code above and also retrieve more meta data about each post?

Sorry this is wooly, if you want URL's of stuff I have implemented I can provide that. I'm just trying to figure out the best approach.

According to this page, the "tweet" parameter

Manages the autotweet (if enabled) for this post: set to off for no tweet, or enter text to override the default tweet

Up until about 3 years ago, I had a Python program that used the Tumblr API to submit draft posts with custom tweet text. Then one day, the tweet text stopped working, and the "tweet preview" text shown in the dashboard viewing the draft showed the main post text instead. I filed this issue:

tumblr/pytumblr#100

Another user verified that the data was being sent correctly through the HTTP request, and that the particular library I was using wasn't at fault. Today I was able to reproduce the issue exactly as 3 years ago with both my minimal Python example code and the other user's Ruby example code, provided in that issue. So it would appear that something is going wrong on the Tumblr side.

I'm a bit confused about the NPF.
Right now we can still create old style posts where you set the post type. Then in archive you can filter by post type and there it is.
If I create a post from the mobile app, it will be NPF (I assume) because I cannot select the type by hand. How will it show in the archive? If I put only one picture? If I put a text and a picture? If I put a picture and a text? And a URL in the end? Does the archived type depend on its structure? Or on the first element? Will a text+picture post will show both under the text filter AND the picture filter? Is there a consistent way to decide the type? What should be my expectations?
</confused>

Based on the docs discouraging usage of the legacy post format, I assumed that NPF was intended to have a superset of the functionality. However, NPF doesn't seem to support monospace/code or syntax highlighting, features that were used even by the NPF announcement! I can emulate code blocks and syntax highlighting myself using the chat subtype, but that doesn't help for inline code at all.

The Inline Format Type: Size section was removed in commit 340c9d9 however the table of contents still has a (now broken) link to that section.

Aside: Is the size type still on the roadmap to be implemented in the future?

The current NPF docs say that the reblog trail has the broken_blog property, with a nested name and avatar. However, the example includes a broken_blog_name property that's mentioned nowhere else in the document. Recently (not sure when), broken reblog trails have stopped including broken_blog entirely. Has the broken_blog property been deprecated and removed?

When issuing the POST /oauth/request_token request, the API docs state that the response:

• should be in JSON, if Content-Type is set to application/json, but I'm getting back URL encoded data for some reason?
• there should be two values returned oauth_token and oauth_token_secret, but I'm also seeing a third value returned for a oauth_callback_confirmed which seems to just be "true"?

Should these properties of the API be documented?

Since yesterday 20 august I receive randomly the error "Limit Exceeded", the response is

{
  "meta": {
    "status": 429,
    "msg": "Limit Exceeded"
  },
  "response": [],
  "errors": [
    {
      "title": "Limit Exceeded",
      "code": 0,
      "detail": "Errorino miserabile. Prova ancora."
    }
  ]
}

The headers in the response contain

HTTP/1.1 401 Unauthorized
Date: Sat, 21 Aug 2021 09:00:02 GMT
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 59
pragma: no-cache
expires: -1

Obviously I don't have reached the calls count limit!

Today (21 august) everything worked fine until the error becomed permanently making unusable the clients

I used my own client and most important the API Console
Any call raises the error

The legacy post creation routes give a human-readable error if something goes wrong, such as "Invalid post id or reblog key" or "You cannot queue more than 300 posts". However, the NPF routes always give a 400 Bad Request error without any explanation of what has gone wrong. Is there a possibility to bring this back?

When looking at the /notifications endpoint documentation:

• it gives for the types parameter a String[] type, but how does an array look for a query parameter??? Any URL example please?
• Anything I send there seems to have zero effect on the response, I always receive all notification types. I tried with types=[like] and types=like and types=[like,reply] and types=like,reply so because of point above I can't tell whether it's my fault or filtering is simply not working.
• it mentions the _links response object however that object is never returned. Do I need to send an undocumented query parameter to get it?
• I could have tried more variants but it's a hassle as the API console doesn't support this endpoint, so here I am asking you :) thank you!

When sending a POST request to the /v2/user/like, I get a 404 or 401 error for some posts. I tried with pytumblr and Postman.

Upon further troubleshooting, I noticed even on tumblr using one of my accounts I can't like those specific posts and I get 403 error on https://www.tumblr.com/svc/like. On one of those specific posts, I noticed the post timestamp is in the future relative to my local time.

This seems to be similar to #6 issue. But I also tried passing the request parameters as JSON and I would still get the same errors.

Any help would be appreciated.

When retrieving a post, even if I specify "notes_info" I receive (understandably) only the first 20 notes. There's no way I can get the further notes. I somehow remember somewhere an API path to retrieve them but I can't find it again and it's definitely not documented here... so how do I retrieve all the notes?

Also, the new post API doesn't specify any "notes_info" (or "reblog_info" for that matter) does it mean retrieving notes is not supported anymore?

The media property of the video content block is shown as having a type of string even though the description says that it is a media object.

The API docs describe the content parameter to be required in a POST /v2/blog/{blog-identifier}/posts call. While this makes sense to create a new post from scratch, if passing this parameter when reblogging with the contents of the post to reblog there is a chance that the content is duplicated. Please update the docs to mention that passing the content parameter is ONLY required if the post being created is brand new and not a reblog.

DontPanic.TumblrSharp.OAuth.OAuthException: 'GetRequestTokenAsync failed. Status Code: Unauthorized, Message: Unauthorized'

For a post that contains an updated vimeo URL, the API response returned conflicting IDs:

{
  type: 'video',
  provider: 'vimeo',
  url: 'https://player.vimeo.com/video/326576684',
  embed_url: 'https://player.vimeo.com/video/325672146?title=0&byline=0&portrait=0&app_id=122963',
  metadata: { id: '326576684' }
}

Expected:
All Vimeo IDs to use the updated ID 326576684.

Actual:
The embed_url contained the original (incorrect) Vimeo ID: 325672146. url and metadata.id contain the new (correct) ID.

This seems to be a bug in the old post format, as well. The results from that returned:
<figure class="tmblr-embed tmblr-full" data-provider="vimeo" data-orig-width="540" data-orig-height="304" data-url="https%3A%2F%2Fplayer.vimeo.com%2Fvideo%2F326576684"><iframe src="https://player.vimeo.com/video/325672146?title=0&amp;byline=0&amp;portrait=0&amp;app_id=122963" width="540" height="304" frameborder="0" title="Save The Internet Act Markup" allowfullscreen=""></iframe></figure>

Expected:
All Vimeo IDs to use the updated ID 326576684.

Actual:
The data-url has the new (correct) ID, but the iframe src contains the old (incorrect) ID.

I'm well authenticated with Oauth1, and when i try to create or edit a post using NPF api it keep respond me with an Unauthorized error

{
   "meta":{
      "status":401,
      "msg":"Unauthorized"
   },
   "response":[

   ],
   "errors":[
      {
         "title":"Unauthorized",
         "code":1016,
         "detail":"Unable to authorize"
      }
   ]
}

When I create a post using the legacy endpoint it work well, same things when I fetch a post using NPF api. But mysteriously it didn't work with creation. Is there anything I missed ?

Probably not the perfect place to ask, but could you comment a bit on the status of the API clients? For instance, Jumblr (the Java client) has PRs open since 2013 and got in 2019 only a readme update... are there any plans to at least have a look at them?

Because it wasn't very obvious (to me) that a correct request has to be:

https://api.tumblr.com/v2/blog/{blog-identifier}/followed_by?query={checked-blog-identifier}

Hello,

I've been working on an app that will read my blog page. The app is registered and its being developed in Python and the Kivy UI.

When testing, I'm logging in multiple times. This issue that I've encountered is that after so many logins, the returned authorized URL has changed.

I'm using Pytumblr to login and typically, the returned authorize URL is similar to:
1.) http://www.tumblr.com/oauth/authorize?oauth_token=blahblahblahblahblah

The last few days, the URL returned is now:
2.) https://api.tumblr.com/console#_=_

then looks like:
3.) https://www.tumblr.com/login?redirect_to=%2Foauth%2Fauthorize%3Foauth_token%3DblahblahblahblahblahPair%26source%3Dconsole&source=console

The 2nd and 3rd URLs are only being returned when I test with the KIVY interface.... I've also noticed that the "source=console" parameter was added.

When I test via cmd-line script, the returned URL is similar to#1.

Do you have any suggestions as to why this has suddenly occurred?

In the NPF documentation for Image content blocks it says:

Image blocks may contain a color field
However, in both the example and table below that paragraph, the field name is shown as colors.

Problem:

Generally, a media array can contain sources that have been

1. resized
2. transcoded
3. or cropped

from the original authored media. However, because the only properties on source are type, width, and height, it's hard to programmatically determine which sources are valid for rendering and which ones should be excluded.

For a simplified example, if I have an array of 2 sources: [250, 100] and [250, 250], which one do I use to render the image? Now, I know by observation that the 250x250 is probably tumblr's square crop derivation. However, that's not a contract that's guaranteed by the API, and it's difficult, cumbersome, and error-prone to hard-code hacks like this into my rendering code. (and what if someone actually uploads an image that's 250x250?)

Right now this information is kind of contained in the image URL, but that has a lot of the same downsides—there are two different URL formats, they may change at any moment, etc.

We should have some authoritative and canonical way of figuring out which media sources are safe to render in what situations.

Proposal:

Add a property that specifies the list of transforms/derivations applied to the media source. Original images would have an empty array, images that were only resized (preserving aspect ratio) would have ['resized'], and 75sq derivations would have ['resized', 'cropped']. API clients can then pick and choose which sources are appropriate for a given situation. Non-cropped sources, for example. Or for a different example, in a full-size viewer, you would only use transcoded media, and exclude resized media.

Alternatives

Alternatively, indicate that some source in a source array is the canonical, original media object, (maybe the first one?) and require clients to figure out what derivations apply themselves. This is less work for the server, but it makes the API client logic more complicated—they need to, e.g. figure out the original aspect ratio, exclude sources that are outside of some epsilon of tolerance (since the aspect ratios of pixel-rounded images are never going to be precisely equal), handle duplicate sources (for the 250x250 case), etc.

I am using the tumblr API, specifically the /posts endpoint with npf=false. I am using pytumblr.

One of the fields in the response is called body and contains HTML. Reblog chains are represented with nested blockquotes, like the way the dashboard used to look a long time ago.

I sometimes encounter posts where the nested blockquotes in body don't correctly convey the structure of the reblog chain.

I am wondering

• Why does this happen?
• Is there a "correct" way to parse legacy format that would handle cases like this?
  • For example, perhaps I should be ignoring body and treating trail (together with answer etc. when applicable) as the source of truth.
• If there is a "correct" way to parse legacy format, could we get it documented in the API docs?
  • For example, if trail should be preferred over body, it would be nice to see this called out.
    • ... ideally with additional documentation on how to correctly parse entries in trail.

If this is simply an inherent problem with legacy format, and the recommended mitigation is to use NPF for post consumption, then it would be nice to add this recommendation to the docs.

An example of the behavior is

https://ofthefog.tumblr.com/post/625973088048300032/i-eat-things-by-breaking-off-small-chunks-and

which is a three-post reblog chain, with a post by ofthefog, then a response by facelessoldgargoyle, and then a response by ofthefog.

If I request this post with a pytumblr client client, by calling

post = client.posts('ofthefog', id=625973088048300032)['posts'][0]

then post['body'] contains the following:

<p><a class="tumblr_blog" href="https://facelessoldgargoyle.tumblr.com/post/625972741512839169">facelessoldgargoyle</a>:</p><blockquote><p>Does this mean you swallowed it whole, or in reasonably large chunks? Or will the future have to reconstruct the skull from tiny tiny fragments?</p><p><a class="tumblr_blog" href="https://ofthefog.tumblr.com/post/625923656553480192">ofthefog</a>:</p><blockquote><p>I ate half of a ram skull today which means that if my body was the crust I would have enough to make at least one reasonably complete fossil. </p></blockquote><p>Also, why? Was it good? Why only half?</p></blockquote><p>I eat things by breaking off small chunks and chewing. I became full, so I stopped. </p><p>I am given to understand this is normal. </p><p>I just like bones. They usually have tasty insides, but the outside makes me have very strong bones. Same with eggshells and horns. </p><p>My body is not the crust so it cannot be reconstructed with human hands. </p><figure class="tmblr-full" data-orig-height="1280" data-orig-width="720"><img src="https://64.media.tumblr.com/04d3ab3e179b1b572df771c91f390756/00d649404253a31c-a0/s640x960/8e6d043e264a667f716018976e813f2337e06931.jpg" data-orig-height="1280" data-orig-width="720"/></figure>

This splits facelessoldgargoyle's post in two, with ofthefog's first post appearing between one paragraph and another one. I'll have github render the same HTML below, to make this visible:

facelessoldgargoyle:

Does this mean you swallowed it whole, or in reasonably large chunks? Or will the future have to reconstruct the skull from tiny tiny fragments?

ofthefog:

I ate half of a ram skull today which means that if my body was the crust I would have enough to make at least one reasonably complete fossil.

Also, why? Was it good? Why only half?

I eat things by breaking off small chunks and chewing. I became full, so I stopped.

I am given to understand this is normal.

I just like bones. They usually have tasty insides, but the outside makes me have very strong bones. Same with eggshells and horns.

My body is not the crust so it cannot be reconstructed with human hands.

I just downloaded an export of a tumblr blog of mine and noticed two problems:

1. Sometimes posts are missing photos.
   e.g. if there's a post named 123456789.html and a photo in the media folder named 123456789.gif, the post html doesn't contain the photo in it. I checked the raw html and there isn't even an empty img html tag. There's just nothing. The text and tags of the post render fine, but the photo is missing.

2. Sometimes posts link to the wrong photo.
   e.g. Say there are two posts, 1.html and 2.html. And two photos: 1.gif, and 2.gif. 2.html embeds 1.gif in it instead of 2.gif.

Given that the documentation mentions that apiFetch uses the native fetch function, it would be useful if the difference in resolve/reject behaviour between the two was documented as well.

It's obvious that apiFetch doesn't resolve or reject with an actual Response object just from using it, but native fetch() doesn't reject at all if the request was successful, regardless of if the server responds with an OK status code. I assume apiFetch is rejecting when the internal fetch's Response.ok is false, but this behaviour is unclear/unexpected until you get a non-OK response for the first time, and there's no documentation to point to if, for example, someone mistakenly implements OK checking when apiFetch has already resolved.

Can you please add data attribute like data-highres or data-orig-url to img tags in NPF posts rendered as text posts?

Now, if I don't want to use NPF and display posts completely through javascript, I have no way to make a lightbox.

Hey, is there any way to retrieve chat messages using the API or is it possible to implement this feature?

I haven't uploaded in a while (maybe since earlier this year or maybe late 2019).

I noticed with an upload tonight that my {PhotoURL-HighRes} is still pulling the correct dimensions photo, the but the quality is awful, it definitely appears to be super lossy compression or something. Has something recently changed from within on how Tumblr is processing uploads and displaying high res images? The quality of my uploads has drastically been reduced.

When calling /user/follow with some okay blog (not sensitive, very public, everything normal) I get the following response:

{
  "meta": {
    "status": 200,
    "msg": "OK"
  },
  "response": {
    "blog": {
      "ask": true,
      "ask_anon": true,
      "ask_page_title": "...",
      "asks_allow_media": true,
      "avatar": [
		{...}
      ],
      "can_chat": true,
      "can_send_fan_mail": false,
      "can_subscribe": false,
      "description": "...",
      "followed": false,
      "is_blocked_from_primary": false,
      "is_nsfw": false,
      "likes": 2880,
      "name": "...",
      "posts": 26783,
      "share_likes": true,
      "subscribed": false,
      "theme": {...},
      "title": "...",
      "total_posts": 26783,
      "updated": 1615809420,
      "url": "https://....tumblr.com/",
      "uuid": "t:..."
    }
  }
}

Notice? It says followed=false. So the operation actually failed even though it answered 200. The headers look okay as well:

X-Ratelimit-Perhour-Remaining=980
X-Ratelimit-Perhour-Reset=3343
X-Ratelimit-Perhour-Limit=1000
X-Ratelimit-Perday-Remaining=4893
X-Ratelimit-Perday-Reset=81297
X-Ratelimit-Perday-Limit=5000

so... there must be something wrong in the documentation some place...

I apologize if this is not the correct channel for this, but I am looking for some clarification/information on implementing Tumblr OAuth authentication in mobile apps (e.g. iOS and Android). Specifically, I'm looking for details around email magic links.

For some context, the OAuth authentication page is opened in a webview inside a mobile app. The password-based authentication works as expected, but the magic link fails. The magic link is sent, but clicking the link opens it in the web browser app (e.g. Safari). This means the authentication flow never actually finishes in app.

• Is there any way to disable the magic link option when opening the authorization view?
• Is there any guidance for supporting magic links in mobile apps?

as far as I can tell, no official clients currently render subtype: indented. What is the authorship intent for subtype indented, and how is it different from quote? (which it seems to be being used in place of)

(i.e., as an author, when would I choose to use one over the other?)

Hi there!

While investigating a recent increase in rate limiting errors, I found that my requests to /v2/blog/{blog}/posts?tag= were coming back with an incorrect total_posts value. Instead of reflecting the number of posts with the given tag, it's the total number of posts on the blog. When passing just the type query param, it behaves correctly.

A lot of older API applications use this field for pagination- in my case, the incorrect value is causing the pagination logic to make as many API calls as there are pages on a given blog, often causing rate limiting errors. I'd like to migrate to using _links anyway since it provides more consistency across endpoints, but regardless, this seems like an unexpected behavior.

Example:
https://api.tumblr.com/v2/blog/cubeghost.tumblr.com/posts?tag=gif
There are only 4 posts in this tag, but total_posts is 364, the total number of posts on the blog.

There's an annoying inconsistency in the API. The Latest posts' output is different from older ones.

https://api.tumblr.com/v2/blog/MY-BLOG/posts/photo/?api_key=MY-API-KEY&offset=80&page_number=5

The newest posts output is like so:
body": "<figure class=\"tmblr-full\" data-orig-height=\"2048\" data-orig-width=\"1365\"><img src=\"https://64.media.tumblr.com/.../s640x960/..85.jpg\" data-orig-height=\"2048\" data-orig-width=\"1365\"></figure><p>description</p>"

But the oldest doesn't have the body, instead they have:

photos": [
    {
        "caption": "",
        "original_size": {
            "url": "https://64.media.tumblr.com/.../tumblr_xxl_1280.jpg",

Both are PHOTO posts. Why is that?

Hey! Time for my weekly npf github issue. So, when I request a tumblr audio element, it comes back from the API with an embed_html property:

{
  "type": "audio",
  "provider": "tumblr",
  "url": null,
  "title": "Superman",
  "artist": "Goldfinger",
  "embed_html": "<iframe class=\"tumblr_audio_player tumblr_audio_player_188362327635\" src=\"https://nightpool.tumblr.com/post/188362327635/audio_player_iframe/nightpool/tumblr_pc5r12Frjn1ti5914?audio_file=https%3A%2F%2Fa.tumblr.com%2Ftumblr_pc5r12Frjn1ti5914o1.mp3\" frameborder=\"0\" allowtransparency=\"true\" scrolling=\"no\" width=\"540\" height=\"169\"></iframe>",
  "media": {
    "url": "https://a.tumblr.com/tumblr_pc5r12Frjn1ti5914o1.mp3?play_key=e6ba8f023e92bbb5aaf06052cd0c6551",
    "type": "audio/mpeg"
  },
  "poster": [
    {
      "url": "https://66.media.tumblr.com/tumblr_pc5r12Frjn1ti5914o1_1532078103_cover.jpg",
      "type": "image/jpeg",
      "width": 500,
      "height": 500
    }
  ]
}

this is cool! however, the iframe comes with the attributes width="540" height="169" and the content doesn't begin to fill that space:

Inspecting the source code, the inner content is 85px tall, and it stretches to fill the space horizontally. It seems like instead this these attributes should be height="85px" width="100%", right?

Today's changelog entry indicates:

 - Displaying nested lists in posts is now supported in the Tumblr mobile apps as of version 17.0.

However, there's no documentation on how this might be achieved in the NPF spec, which still says:

Note that NPF does not allow nested lists or non-text-based lists at this time.

This seems like a deficiency that should be corrected!

You invite people to discuss stuff on the Tumblr API Google group, but the group does not accept new members so it's basically impossible to ask stuff there. Is that by design?

Hi! I'm a tumblr user and developer, and one thing that would absolutely help make tumblr a safer place would be the ability to manage blocks via the API; Currently I can do this if logged in by issuing the right "internal" API calls at a reasonably rate limited speed, but I have to go one-by-one.

By allowing developers to write tools to help manage their communities on tumblr, it'll make the place safer for everyone. For instance, I've a script that blocks all blogs that follow me who lack any name/bio, lack any age in their bio (I don't wish to interact with children on tumblr), and then it'd be even helpful to be able to share and collaborate on blocklists to filter out abusive users (terfs, nazis, incels, etc).

Would it be possible to get an API to block blogs? This would enable people to take moderating their communities into their own hands, making tumblr a better place for all.

is web-platform.md supposed to be published anywhere, or is this repo the authoritative reference for it? https://www.tumblr.com/docs/web-platform does not seem to work, nor do several other common spellings for it

Don't know if it's possible, but could there be a class name in the map that distinguishes when a reblog post has new content by the person posting it? There was a previous class for ".contributed-content", and I can't find anything that looks similar in the cssMap? If I'm overlooking something basic, just let me know.

Despite using tumblr as a user, and having followed the privacy consent dialog, after authorising with the API, the API returns back responses to methods such as /v2/user/dashboard and /v2/user/info as being 303 Redirects to the privacy consent page.

An example response was:

{
  status: 303,
  headers: {
    server: 'nginx',
    date: 'Tue, 24 Aug 2021 15:54:38 GMT',
    'content-type': 'text/html; charset=UTF-8',
    'content-length': '0',
    connection: 'keep-alive',
    'x-rid': '07f571380157b5900ef081e5908e4c6c',
    p3p: `CP="Tumblr's privacy policy is available here: https://www.tumblr.com/policy/en/privacy"`,
    location: 'https://www.tumblr.com/privacy/consent/begin?redirect=https%3A%2F%2Fwww.tumblr.com%2Fv2%2Fuser%2Fdashboard',
    'x-ua-compatible': 'IE=Edge,chrome=1',
    'strict-transport-security': 'max-age=31536000; preload'
  },
  body: ''
}

Whilst I've been writing my own API client in node.js (instead of using the official one), I can't find anything in the official one's source code as to how to deal with this either, so I think it's affecting there too.

This would mean your API has been broken for requests originating from within the EU for however long the cookie consent banner has been in place. I haven't been able to test from the US (ex. california) yet, as my VPN provider is having issues.