Why does the Meta Threads API make me feel so disappointed?

2024-07-18

文末有中文版本

Preface

To be honest, I'm quite lazy when it comes to writing articles. When you see that I'm writing this article about the Threads API, you'll understand the intense frustration I have towards it. For those who don't know, the Threads API is an official third-party code interface released by Threads for developers to call certain development capabilities. When Threads released their API on June 18th, I was very excited and immediately began researching and developing an independent product. However, it only took a month (today is exactly July 18th) for me to become completely disappointed with the Threads API. Let me explain what exactly happened.

The Cost and Complexity of Integrating the Threads API

I independently developed a product called ThreadsDashboard, which is a Threads data analysis product based on the official API of the Meta Threads app. You can see key data indicators and trend graphs about your Threads account, such as the number of followers, post exposure, reposts, likes, etc.

The implementation of this product was quite fast. Using a series of technology stacks like Nextjs, the route to creating such a product is quite clear. Throughout the development process, the most difficult and complex part was the Threads API itself. Here are a few incomprehensible points:

The Entry for Publishing and Reviewing is Hard to Find

Threads API requires you to have a business identity to successfully call it online. However, this information is not reflected anywhere. After you create a Threads application, you will see the following screen:

Even after you complete the "Required Actions," "Usage Examples," and "Testing" sections on the left, you still only see the screen above, with no entry for publishing or reviewing. Your test account can call the API online, but people around you cannot access it, being told they are not test users of your application. I was stuck here for a long time. I thought maybe there was an issue with my code or my permissions application was incorrect. The answer was neither. When I couldn't find a solution, I started trying anything possible. I noticed a prompt on the screen to become a tech provider. I clicked it and discovered a new world, as shown below:

I couldn't understand it at all. I could understand every word, but I didn't know why I needed to become a tech provider. Wasn't I already developing the application? What benefits would becoming a tech provider bring? Could I help other businesses develop their Threads applications? Despite my confusion, I had no choice. I chose "Yes, I’m a Tech Provider," and then everything became available – review and publishing options appeared.

Publishing Without Review

After completing a series of business company certifications and data and permissions certifications, I could finally publish. I excitedly clicked publish and went live. After going live, nothing happened. People around me were still prompted that they were not test users and couldn't log in. Why? I couldn't understand. I thought hard and realized the problem – I hadn't applied for a review. Here, I couldn't understand even more. Why could an application be published without review? Why wasn't I prompted that review was necessary before publishing? I have no answers to these questions.

Is It Safe Once Published?

After the application went live and had been running for a while, I suddenly found that the API calls weren't working. Every request returned "Error 100, unsupported GET request type." You might think this was due to a coding error in the API request or a network issue. I spent a day and a night thinking hard and trying various code modification methods, but nothing worked. Finally, I discovered that there was an additional tech provider access certification in the authentication module. I had no choice but to try it, and after applying, the API error disappeared, and it started working again.

I still can't understand how an application that was already live suddenly had its API calls fail due to an unapproved certification, with no email notifications before or after the approval.

Frequent API Failures

I launched this project on ProductHunt and achieved a top 10 ranking for the day, making it onto the daily email. This brought a surge of traffic to the product. However, at the peak of the traffic, I found that I couldn't log into the product. The OAuth login of the Threads API had an issue, and it couldn't redirect back to the product page.

Discussion on the issue: https://developers.facebook.com/support/bugs/826540452907203/

It's normal for products to have issues and for APIs to fail. Encountering a failure at the peak of traffic was just bad luck for me. So, I posted a product failure notice and waited for the official fix. There was nothing else I could do. It took almost 10 hours for the issue to be resolved, perfectly missing the traffic peak.

From the history, you can see that there was also a failure on June 19th:

Is This the End?

No, it's not. The trigger for writing this article was that the Threads API has failed yet again. Now, it returns a 500 system error for all requests, and none of the data can be accessed. Customers cannot use any features of the platform. As of writing this article, almost three hours have passed, and the official API Status still shows everything as normal. Maybe they haven't woken up yet and don't realize that as third-party service providers, we've already been down for three hours. Helplessly, I posted another failure notice and waited for the official fix. I don't know how long it will take this time...

Conclusion

Maybe next time, I'll learn to be more cautious when developing based on Meta products.

以下是中文版本：

为什么 Meta Threads API 让我感觉到无比失望？

前言

别的不说，我是很个懒得写文章的人，当你看到我能够为了 Threads API 写这篇文章，你就能感受到我对 Threads API 难以表达的愤恨之情。如果有人还不知道 Threads API 是什么，它是 Threads 官方放出的第三方用于开发程序调用 Threads 部分开发能力的代码接口。其实，在 Threads 6.18 号放出他们的 API 的时候，我还是十分激动的，立马就开始研究开发独立产品了。没想到，只用了短短一个月的时间（今天正好是 7.18），我对 Threads API 就失望透顶。以下我来解释一下到底发生了什么。

Threads API 的接入成本和配置复杂

我独立开发的一款产品叫 ThreadsDashboard ，这款产品是基于 Meta Threads app 的官方 API 制作的 Threads 数据分析产品，可以在上面看到关于你 Threads 账号的粉丝数、帖子的曝光数、转发、点赞等关键数据指标和变化的趋势图。

这块产品的实现其实很快，通过 Nextjs 等一系列技术栈，实现一个这样的产品的路线还是很清晰的。在整个研发过程中，最难最复杂的反而就是 Threads API 本身。以下是难以理解的几个点：

发布与审核的入口难以发现

Threads API 要求必须要是企业身份才能真正在线上调用成功。然而这个信息，没有任何地方体现出来。在你建立一个 Threads 应用之后，你会看到以下画面：

当你把左侧的“要求动作”、“使用示例“、”测试“ 都完成之后，你仍然只能看到上面这一画面，没有任何发布上线的操作入口或是审核入口。你自己的测试账号也可以在线上调用通过，但是你周围的人怎么样也打不开，提示他不是你应用的测试用户。 我在这里卡住了很久，我以为是我的代码出现了问题，或者是不是我权限申请的不对。答案都不是，当我实在找不到解法之后，我开始尝试任何的可能性。我发现画面上有个提示，让你成为技术提供者。我点击了一下，发现了新大陆，如下图：

看不懂，完全看不懂。每个字都能看懂，但是我就是不知道我为什么要作为一个技术提供者。我已经在开发应用了不是吗？成为技术提供者，能获得什么？是我可以帮其他商业公司开发他们的 Threads 应用了吗？ 尽管我如此困惑，但是实在没办法了，我还是选择了“Yes, I’am a Tech Provider”。然后就有了一切，可以审核和发布了。

不用审核就可以发布

在完成了一系列的商业公司认证，数据与权限认证，终于可以发布了。我激动的点了发布，上线了。上线之后，什么也没发生。我周围的人仍然是提示非测试用户无法登陆。为什么？我不能理解。我左思右想，发现问题了，还没申请审核。到这里，我更不能理解了，没审核的应用为什么能发布上线？发布上线之前为什么不提示我必须要审核？这些问题，我没有答案。

发布上线就安全了吗

在上线了之后，已经运行了一段时间，突然发现 API 调用不通了。任何请求都返回”错误 100，不支持的 GET 请求类型“。这个时候，你可能以为是不是 API 请求代码写错了，或者是网络出了问题，官方出了问题等等。我苦想了一天一夜，尝试了各种代码修改方法，仍然没有任何反应。最后，我发现，其实是认证模块里面，多了一个技术提供者的访问认证，我想也没办法了，就试试吧，结果申请通过之后，API 错误消失了，可以调通了。

我到现在还是无法理解，一个应用都上线了，怎么会突然 API 就掉不通，是因为一个认证没有认证，且前后都没有邮件提醒，哪怕是审核通过了也没有邮件提醒。

API 频繁的故障

我在 ProductHunt 上 launch 了这个项目，并获得了当天的前 10 名的成绩，并登陆上了每日邮件。也有了一大波流量，访问这个产品。结果，就在流量最高峰的时候，我发现我登录不上了产品了。Threads API 的 OAuth 登录出现了问题，没有办法重定向回到产品页面。

故障的讨论地址：https://developers.facebook.com/support/bugs/826540452907203/

产品出现问题很正常，API 故障也正常，在流量最高峰的时候碰到故障，只能说我比较倒霉罢了。于是，我就挂上了产品故障公告，等着官方修复，也没什么办法好做的。等了将近 10 个小时，这个故障才修复完成，完美错过了流量高峰。

从历史上看到看到，6 月 19 号也发生了故障：

这就结束了吗？

并没有，我写这篇文章的导火索，是因为现在 Threads API 又又又挂了。现在全部返回 500 系统错误，所有数据都调不通，客户无法使用平台的任何能力。截至到我写这篇文章，已经过去了将近 3 个小时，官方的 API Status 仍然显示一切安好，可能他们还没有睡醒，不知道作为第三方服务商，我们都已经故障了 3 个小时。无奈，我又挂上了故障公告，等待官方的修复，这次不知道又要多久…

结语

也许下一次，我会学会谨慎对待基于 Meta 产品的开发。