#1

Today, we want to share early thinking about how we might implement new follow, block, and mute endpoints.

As we build the next generation of the Twitter API, we’re looking at how to rebuild the “follower graph” endpoints. Whether or not you’ve used the follow, search, and get users, or the mute, block and report users endpoints, we want to hear what you think. This is an effort to continue building in the open: sharing our roadmap and keeping you updated on our vision. As we have done in Twitter Developer Labs, this plan is not final, and with your feedback, will evolve over time.

Below is a synopsis of our vision for what the follow, block, and mute endpoints might look like in the future. Many of the proposed improvements are based on feedback we’ve already received, but if you have additional ideas or questions about the current or future state of these endpoints, we’d love to hear from you!

Design principles

Based on feedback, we’re using the following design principles to model these endpoints:

  • Compatibility
    Developers want the core functionality of the original v1.1 endpoints intact. This includes the ability to manage follow, block, and mute actions on behalf of a person on Twitter. It also includes the ability to get the public relationship status between two people on Twitter.

  • Full user objects
    Developers want the ability to request additional user fields including pinned Tweets, location information (for people who have this feature enabled), or inferred language in the same request as getting lists of followed, blocked, or muted accounts. Currently, to do so, developers will need one call to the friendship endpoint, and a subsequent user lookup request.

    We’re considering enabling the return of full user objects via GET endpoints, allowing developers to use fields and expansions to request additional details (similar to the design we’re previewing in Labs). For each person you may be able to build advanced calls to obtain objects like pinned Tweets, location information, or inferred language.

Currrent Proposed
/friendships/show.json?source_screen_name=leet&target_id=TheAnswer /users/by/username/leet/relationship/by/username/TheAnswer?user.fields=created_at,pinned_tweet_id,location,verified,public_metrics
{
  “relationship”: {
    “source”: {
      “id”: 1337,
      “id_str”: “1337”,
      “screen_name”: “leet”,
      “following”: true,
      “followed_by”: true,
      “live_following”: false,
      “following_received”: null,
      “following_requested”: null,
      “notifications_enabled”: null,
      “can_dm”: true,
      “blocking”: null,
      “blocked_by”: null,
      “muting”: true,
      “want_retweets”: null,
      “all_replies”: null,
      “marked_spam”: null
    },
    “target”: {
      “id”: 42,
      “id_str”: “42”,
      “screen_name”: “TheAnswer”,
      “following”: true,
      “followed_by”: true,
      “following_received”: null,
      “following_requested”: null
    }
  }
}		 {
  “data”: [
    {
      “id”: “1337”,
      “name”: “l33t”,
      “username”: “leet”,
      “created_at”: “2018-07-20T00:50:42.000Z”,
      “pinned_tweet_id”: “956629397260641280”,
      “location”: “In the cloud”,
      “public_metrics”: {
        “followers_count”: 1501,
        “following_count”: 2067,
        “tweet_count”: 10752,
        “listed_count”: 33
      },
      “verified”: true,
      “relationship”: [
        “source”
      ]
    },
    {
      “id”: “42”,
      “name”: “The Answer”,
      “username”: “TheAnswer”,
      “created_at”: “2009-08-05T05:46:48.000Z”,
      “pinned_tweet_id”: “856629387260641280”,
      “location”: “Boulder, CO”,
      “public_metrics”: {
        “followers_count”: 151,
        “following_count”: 267,
        “tweet_count”: 175,
        “listed_count”: 3
      },
      “verified”: false,
      “relationship”: [
        “dm_by_source”,
        “followed_by_source”,
        “following_source”,
        “muted_by_source”
      ]
    }
  ]
}
  • Modern design and scalability
    Developers expect a modern design, similar to what we shipped with Tweets and Users in Labs v2. We heard that accessing data in batches will allow you to better store, parse through and analyze large amounts of follower data; this is important when performing deep follower network analysis, or to compute the intersection between followers and a larger superset of people on Twitter. Developers will need a more sustainable, scalable way to explore a larger follower network than the original endpoints allow. We hear this request and are thinking about how we might solve it in a way that honors the responsibility we have to everyone on Twitter.

Proposed solutions

As we define the next generation of the follow, block, and mute endpoints, we’re considering the following solution areas. Although it is not confirmed that we will build support for all of these items, here’s what we’re thinking:

  • Manage follows, blocks, and mutes
    One of the core functions of these endpoints is the ability to manage follows, blocks, and mutes. Developers can help their clients engage with followers to grow their follower network, while also helping them avoid and manage abusive language or accounts. We’re exploring a solution to extend these endpoint functionalities to allow protected accounts to accept or deny follower requests as well.

  • Explore followers in new ways
    Many developers asked us to include time-series data to better understand how a person’s follower network changes over time. Use cases may include researchers analyzing what external circumstances determine changes in followers, or social media management companies creating analytics platforms to better understand and measure engagement between a brand and its follower base. Additionally, this would allow developers to see recent follower changes and understand the difference in customer’s followers since their last call.

  • Deeper levels of analysis
    We’re exploring a solution to allow developers to go “one level deeper” by analyzing a list of follower’s followers with a reduced number of API calls. This functionality would enable deeper follower network analysis by allowing you to look at a person’s followers and everyone who follows those people.

  • Easier access to large sets of relationship data
    We understand that not all developers need, or even want, continuous access to data. We’re exploring a solution to allow approved developers the opportunity to access batch data for a specified number of people on Twitter in one request. This would enable you to store, parse through, and analyze large amounts of follower data without having to spend time and resources on continuous requests.

We want to emphasize that we are still in the definition phase. We’re listening to your feedback and expect to share these endpoints with you as part of the next generation of the Twitter API. These endpoints will evolve over time, and we may not be able to include all proposed solutions in the final versions. That said, we want this to be an open conversation and welcome any and all feedback on these endpoints and the functionality we are building.

Head to our feedback page to leave additional suggestions on the follow, block, and mute endpoints. We can’t wait to hear from you!

2 Likes
#2