自定义站内通知
将自定义站内通知解决方案/提供商集成作为您运营商 API 的一部分
Fast Tracks 支持两种不同的站内通知提供商，我们自己的和"运营商 API 提供商"，这意味着您可以在您这边做任何您想做的事情。
Fast Track 站内通知服务
以下端点可以作为您运营商 API 的一部分构建：
⬆️ POST /channels/site/single
⬆️ POST /channels/site/batch
运营商然后可以将这些请求转发到站内通知系统进行处理，并用相应的响应回答。
前提条件
- 如果需要考虑任何速率限制，请通知 Fast Track。（如果您计划实施速率限制，请事先联系 Fast Track，以便我们可以指导您支持的实施方案）
- 如果需要考虑任何批量最大值，请通知 Fast Track。
- 向 Fast Track 提供集成提供商的任何特定凭据（如果需要）
发送站内通知（单个）
单个站内通知发送请求将在单独的 API 请求中包含每个单独通知的数据。
端点实现
按照以下格式实现端点，以支持通过 API 单发站内通知。
⬆️ POST <operator-api-base-url>/channels/site/single
请求头
发送请求的头部包含一个 x-api-key，这是在端点验证 API 调用所需的令牌。此令牌需要传递给 Fast Track 以进行这些请求。
请求体架构
参考以下 Fast Track 发送的单个通知请求示例。每个字段的描述列在下面的表格中。
| 键 | 类型 | 描述 |
|---|---|---|
activity.id * | integer | 站内通知的唯一标识符 |
activity.brand_id * | integer | Fast Track 上品牌的唯一标识符 |
activity.user_id * | string | 玩家的唯一标识符 |
activity.activity_id * | integer | Fast Track 中设置的活动的唯一标识符 |
activity.action_group_id * | integer | 站内通知来源于 Fast Track 的操作组的唯一标识符 |
activity.trigger_hash * | string | 触发器哈希 |
activity.action_id * | integer | 来自 Fast Track 的单个操作的唯一标识符 |
event * | string | "inbox" -> 富收件箱消息
"message" -> 小弹窗
"shoutout" -> 大弹窗 |
display_type * | string | "silent" -> 静默通知
"push" -> 屏幕推送通知 |
title * | string | 通知标题 |
message * | string | 通知正文文本 |
preview_text | string | 在打开通知之前显示的简短预览文本 |
footer_text | string | 在通知页脚显示的文本 |
image_url | string | 在通知中显示的图像 URL |
cta_button_link | string | 主要行动号召按钮的 URL |
cta_button_text | string | 主要行动号召按钮的标签 |
cta_button_2_link | string | 次要行动号召按钮的 URL |
cta_button_2_text | string | 次要行动号召按钮的标签 |
expires | integer | Unix 时间戳，之后通知应被视为过期 |
meta | object | 在 Fast Track CRM 活动中定义的自定义键值对 |
预期响应
运营商 API 应该分别为每个单独的站内通知消息返回响应，以避免不相关的站内通知数据存储。
成功 HTTP 200-299 JSON 响应
site_notification_id 将是运营商 API 生成的唯一标识符，它允许 Fast Track 识别特定的站内通知消息，以便在发送后更新其传递状态。
错误 非 200 响应 JSON 响应
错误响应通常与 HTTP 状态码 400s 或 500s 相关。响应应该包含一个"error"字段，描述出了什么问题并协助故障排除。
运营商 API 的响应将根据 HTTP 状态码的类别进行不同处理。下表总结了 HTTP 状态如何分别处理。
| HTTP 状态码 | 描述 |
|---|---|
200-299 | 成功传递。Fast Track 将确认消息并开始处理队列中的下一条消息。 |
400-499 | 不成功。收到此错误时，Fast Track 将跳过站内通知消息。此外，如果启用了服务，它将把数据发送到失败操作。 |
500 或任何其他未在上面列出的状态码 | 不成功。服务出现致命错误，Fast Track 将继续重试，直到收到 200 响应。 |
批量站内通知
批量站内通知有助于在一个 API 请求中处理站内通知集合。批量请求中的消息数量受配置中设置的整数限制，并在配置的时间跨度内发送，即使批量尚未满。
端点实现
按照以下格式实现端点，以支持通过 API 批量发送站内通知。
⬆️ POST <operator-api-base-url>/channels/site/batch
请求头
发送请求的头部包含一个 x-api-key，这是在端点验证 API 调用所需的令牌。此令牌需要传递给 Fast Track 以进行这些请求。
请求体架构
这是批量请求的预期格式示例。它类似于单个站内通知请求，但请求存储在数组中，一个接一个。
请参见上表（/site/single）以获取描述每个属性的表格。
预期响应
运营商 API 应返回以下响应。
成功 HTTP 200 JSON 响应
请求中最初发送的"activity.id"将在响应中作为"id"返回。这是帮助 Fast Track 在初始批量请求中识别单个站内通知消息所必需的。
site_notification_id 将是运营商 API 生成的唯一标识符，Fast Track 将使用它在更新状态时识别相关的站内通知消息。
如果任何列出的类别（"successful"、"failed"或"fatal"）没有关联的站内通知，它们应该作为空数组返回。
请求需要包含属性 successful、failed 或 fatal 中的一个
响应处理的逻辑流程与单个