API Integration Issues

Hello @Evan Zhao （赵念青）,

Thank you for your email! We are currently reviewing your request and will follow up with more information shortly.
感谢您的电子邮件！我们目前正在审核您的请求，并将很快提供更多信息。

Cheers,  干杯，
David  大卫

Hello team,  大家好，

Please find below answers to the Radarly questions
以下是 Radarly 问题的答案

API (New) Integration Issues: Data Synchronization Mechanism
API（新）集成问题：数据同步机制
What are the mechanisms and time intervals for the Meltwater library's integration with various social media platforms? For example, how often does Facebook sync (e.g., every few minutes)? Additionally, what are the issues related to the pagination size and index time fields for single requests?
Meltwater 库与各种社交媒体平台集成的机制和时间间隔是什么？例如，Facebook 同步的频率是多少（例如，每隔几分钟）？此外，单个请求的分页大小和索引时间字段相关的问题是什么？

Once a query is implemented in a project, the post updates are on a best-effort basis. And they will vary between each platform on Radarly. For the Meta platforms, there can be some hours of delay between the post publication and its capture in Radarly. If one owns the accounts, the best way to ensure a reliable (and near-realtime) data acquisition is to plug the accounts in Radarly.
一旦在项目中实施了查询，帖子更新将尽最大努力。它们在 Radarly 上的每个平台上都会有所不同。对于 Meta 平台，帖子发布和 Radarly 捕获之间可能会有几个小时的延迟。如果某人拥有这些账户，那么确保可靠（且接近实时）数据采集的最佳方法是将账户插入 Radarly。

The posts that match the request are captured in real time for Twitter/X. There may be some lag for Blogs / Media / Site type platforms (because of the RSS feed verification that takes time or delay in one of our suppliers for forums ...)
符合请求的帖子会被实时捕获到 Twitter/X 中。博客/媒体/网站类型平台可能会出现一些延迟（因为我们的论坛供应商之一的 RSS 提要验证需要时间或延迟...）

For pagination size and index time fields this depends more so on the rate limit of the route being explored.
对于分页大小和索引时间字段，这更多地取决于正在探索的路线的速率限制。

The rate limiting of API provides a way to limit the number of requests made by a client in a time-span. If a method allows for 100 requests per rate limit window, then it allows you to make 100 requests per window per leveraged access token. Rate limits are divided into 15 minute intervals. Since endpoints require authentication, so there is no concept of unauthenticated calls and rate limits.
API 的速率限制提供了一种限制客户端在一段时间内发出的请求数量的方法。如果一种方法允许每个速率限制窗口发出 100 个请求，那么它允许您每个窗口每个利用的访问令牌发出 100 个请求。速率限制分为 15 分钟的间隔。由于端点需要身份验证，因此不存在未经身份验证的调用和速率限制的概念。

The time window is sliding, that means the number of requests left for a token is equal to : MaxRequestNumber - (number of requests in the last X minutes)`
时间窗口是滑动的，这意味着令牌剩余的请求数等于： MaxRequestNumber - (number of requests in the last X minutes)`

The number of results (pagination) for a request can be limited (for example: max 10,000 posts for search) so regarding the number of documents, one request could need several calls to get the full list of results.
请求的结果（分页）数量可能受到限制（例如：最多搜索 10,000 个帖子），因此就文档数量而言，一个请求可能需要多次调用才能获得完整的结果列表。

Index Time Issues  索引时间问题
Does the index time always have to be less than the current time? For example, when searching for data at 10:00, if createBefore = 10:00 and createAfter = 09:45 or 10:15, will the search results be consistent when using the same index time range?
索引时间一定要小于当前时间吗？比如搜索10:00的数据，如果createBefore = 10:00，createAfter = 09:45或者10:15，使用相同的索引时间范围，搜索结果会一致吗？

The date types here are another way to filter the data to the timeframe you want to retrieve. If you want to search for data specifically captured at 10:00, set createdBefore = 10:01 and createdAfter=09:59.
此处的日期类型是另一种筛选数据到您想要检索的时间范围的方法。如果您想要搜索在 10:00 捕获的数据，请设置 createdBefore = 10:01 和 createdAfter=09:59。

More commonly you could also use from and to date metrics:
更常见的是，您还可以使用从日期到日期的指标：

Below is a sample for writing a date range from August 15, 2024 through September 15, applying the PST timezone.
下面是一个示例，使用 PST 时区编写从 2024 年 8 月 15 日到 9 月 15 日的日期范围。

"from":"2024-08-15T00:00:00-07:00",
"来自"："2024-08-15T00:00:00-07:00",
"to":"2024-09-15T23:59:59-07:00",
“至”：“2024-09-15T23：59：59-07：00”，

Engagement Data Update Issues
参与数据更新问题
When engagement data (shares, likes, comments) is updated, does the index time also get updated? Is there an API endpoint to query the content of a single post?
当参与度数据（分享、点赞、评论）更新时，索引时间是否也会更新？是否有 API 端点可以查询单个帖子的内容？

For individual posts we log the ingested time of the post as well as the most recent update time of the post which can be found under the search endpoint results.
对于单个帖子，我们会记录帖子的摄取时间以及帖子的最近更新时间，可以在搜索端点结果下找到。

API document link
API文档链接

For example:  例如：

Quota Usage and AccessToken Refresh Issues
配额使用和 AccessToken 刷新问题
How can we check the current quota usage and remaining balance?
如何查看当前配额使用情况及剩余余额？

The quota usage isn’t documented however we have the rate limiting per endpoint defined below.
虽然没有记录配额使用情况，但是我们在下面定义了每个端点的速率限制。

Each rate-limited route limit requests depending on its policy. Rate limit is made per route and per token. Restricted Methods :
每个限速路由根据其策略限制请求。速率限制是针对每个路由和每个令牌进行的。受限方法：

• Search: 180 calls / window
  搜索：180 次呼叫/窗口

• Influencer: 60 calls / window
  影响者：60 次通话/窗口

• WordCloud: 60 calls / window
  WordCloud：60 次呼叫/窗口

• Statistics: 60 calls / window
  统计：60次呼叫/窗口

• Document: 180 calls / window
  文档：180 次调用/窗口

• Document Metrics: 180 calls / window
  文档指标：180 次调用/窗口

• Pagination of results  结果分页

In the oauth2/token interface, using grant_type=client_credentials also refreshes the AccessToken. Does this mean we can ignore the usage of grant_type=refresh? What is the difference between these two?
在 oauth2/token 接口中，使用 grant_type=client_credentials 也会刷新 AccessToken。这是否意味着我们可以忽略 grant_type=refresh 的用法？这两者有什么区别？

Technically the generation of a new access token can be done to refresh but we have a dedicated path to refresh the same access token. Documentation links are attached here.
从技术上讲，可以生成新的访问令牌来刷新，但我们有专用路径来刷新相同的访问令牌。文档链接附在此处。

Refresh Access token  刷新访问令牌

Request  要求

POST https://oauth.linkfluence.com/oauth2/token

Headers  标头

• Content-Type: application/x-www-form-urlencoded
  内容类型： application/x-www-form-urlencoded

Post data parameters  发布数据参数

• refresh_token: <REFRESH_TOKEN>
  刷新令牌：

• grant_type: refresh_token
  授予类型： refresh_token

• client_id: (string)
  client_id ：（字符串）

• client_secret: (string)
  client_secret ：（字符串）

Curl Example:  卷曲示例：

What are the meanings of the fields intended for internal use only, and how can we confirm them?
仅供内部使用的字段含义是什么，如何确认？

Anything outside of our documented fields will typically be for internal use only. The internal fields relate to the Radarly UI usage or internal tracking.
我们记录的字段之外的任何内容通常仅供内部使用。内部字段与 Radarly UI 使用或内部跟踪有关。

For tags assigned to data on social media, can they be retrieved directly from the text field, or do we need to extract them from other fields?
对于分配给社交媒体上的数据的标签，可以直接从文本字段中检索它们，还是我们需要从其他字段中提取它们？

The text fields can be used on posts to retrieve all of the post text, including hashtags. Key phrases or keywords will be populated depending on the query used to capture it into the platform.
文本字段可用于帖子，以检索所有帖子文本，包括主题标签。关键短语或关键词将根据用于将其捕获到平台中的查询进行填充。

If the data pull exceeds the quota, what error does the API return?
如果数据拉取超出配额，API 会返回什么错误？

The error returned would be a 429 rate limit error.
返回的错误将是 429 速率限制错误。

Content Access and Data Missing Issues
内容访问和数据丢失问题
It is necessary to ensure that images and videos provided by Meltwater can be accessed normally. However, we have noticed that some retrieved images and videos are still inaccessible, which is inconsistent with what Hugo mentioned before. In cases of missing or unusable data, how should both parties collaborate to resolve the issue?
需要保证 Meltwater 提供的图片和视频可以正常访问，但是我们发现部分检索到的图片和视频仍然无法访问，这与 Hugo 之前说的不一致，如果出现数据丢失或无法使用的情况，双方该如何配合解决？

 

Please feel free to raise any missing images or videoes to us by supplying the Radarly link which corresponds to the API search as well as the request body/route used. You can reach us by mentioning the Radarly API in your email subject line to help@meltwater.com.
如果您发现任何缺失的图像或视频，请随时向我们提供与 API 搜索对应的 Radarly 链接以及使用的请求正文/路由。您可以在发送至help@meltwater.com的电子邮件主题行中提及Radarly API来联系我们。

Best,  最好的，

Adam  亚当