Automatisch 中 Ghost 触发器实战New Post Published 的接入原理与流程配置【免费下载链接】automatischThe open source Zapier alternative. Build workflow automation without spending time and money.项目地址: https://gitcode.com/GitHub_Trending/au/automatisch本文围绕 Automatisch 对 Ghost开源博客平台的官方触发器「New post published」展开讲解该 Webhook 触发器的能力边界、连接配置、底层实现原理以及如何在一个自动化流程中订阅「新文章发布」事件并消费其数据负载。读完本文你将掌握在 Automatisch 中为 Ghost 创建连接、配置流程、启用/停用该触发器的完整方法并理解其背后基于 Ghost Admin API Webhook 的事件订阅机制。Ghost 触发器一览当前版本只有一个事件在 Automatisch 的 Ghost 应用中官方目前提供的触发器记录在 packages/docs/pages/apps/ghost/triggers.md 中内容非常聚焦——当前仅有一个触发器名称触发条件New post published当一篇新文章post发布时触发该触发器的类型为webhook而非轮询意味着 Automatisch 不会定时去抓取 Ghost 的接口而是由 Ghost 在文章发布事件发生时主动把数据推送到 Automatisch 生成的 Webhook 地址上。这在事件及时性、请求开销两方面都优于轮询方案。在源码层面触发器注册于 packages/backend/src/apps/ghost/triggers/index.jsimport newPostPublished from ./new-post-published/index.js; export default [newPostPublished];而应用app本身的声明位于 packages/backend/src/apps/ghost/index.jsexport default defineApp({ name: Ghost, key: ghost, baseUrl: https://ghost.org, apiBaseUrl: , iconUrl: {BASE_URL}/apps/ghost/assets/favicon.svg, authDocUrl: {DOCS_URL}/apps/ghost/connection, primaryColor: #15171A, supportsConnections: true, beforeRequest: [setBaseUrl, addAuthHeader], auth, triggers, });从这里可以看到 Ghost 应用的几个关键事实它通过supportsConnections: true支持连接凭据管理所有出站请求都会经过setBaseUrl与addAuthHeader两个前置钩子统一处理 URL 与鉴权头。前置条件先建立 Ghost 连接在使用「New post published」触发器之前必须先在 Automatisch 中创建一条 Ghost 连接。官方操作指引记录在 packages/docs/pages/apps/ghost/connection.md步骤如下登录你的 Ghost 后台Ghost Admin panel。点击Integrations集成按钮。点击Add custom integration添加自定义集成创建一个 Admin API Key管理 API 密钥。在 Automatisch 的Admin API Key字段中填入该密钥。在 Automatisch 的Instance URL实例地址字段中填入你的 Ghost API URL例如https://your-blog.example.com。点击Submit提交。连接建立成功后即可在流程中开始使用该连接。两个必填字段的源码视角连接表单定义在 packages/backend/src/apps/ghost/auth/index.js包含两个required: true的字段Instance URLinstanceUrlstring你的 Ghost 站点地址Admin API KeyapiKeystring由 Ghost 自定义集成生成的 Admin API 密钥。这两个字段的实际作用在请求钩子中体现得淋漓尽致。Instance URL 如何变成 API 地址packages/backend/src/apps/ghost/common/set-base-url.js 会在每次请求发出前拼接基础 URLconst setBaseUrl ($, requestConfig) { const instanceUrl $.auth.data.instanceUrl; if (instanceUrl) { requestConfig.baseURL ${instanceUrl}/ghost/api; } return requestConfig; };即最终所有 API 请求都会被定向到instanceUrl/ghost/api之下配合后续的/admin/webhooks/、/admin/site/等路径使用。Admin API Key 如何完成鉴权Ghost 的 Admin API Key 形如{id}:{secret}。鉴权逻辑位于 packages/backend/src/apps/ghost/common/add-auth-header.jsconst addAuthHeader ($, requestConfig) { const key $.auth.data?.apiKey; if (key) { const [id, secret] key.split(:); const token jwt.sign({}, Buffer.from(secret, hex), { keyid: id, algorithm: HS256, expiresIn: 1h, audience: /admin/, }); requestConfig.headers.Authorization Ghost ${token}; } return requestConfig; };可以看到Automatisch 用:切分密钥的id与secret以 HS256 算法签发一个1 小时有效、audience为/admin/的 JWT并以Authorization: Ghost token的形式附加到请求头。这完全遵循 Ghost Admin API 的官方鉴权规范因此任何符合该规范的 Ghost 实例包括自托管 Ghost都能接入。连接验证的底层逻辑提交连接时Automatisch 会调用 packages/backend/src/apps/ghost/auth/verify-credentials.js 做连通性校验const verifyCredentials async ($) { const site await $.http.get(/admin/site/); const screenName [site.data.site.title, site.data.site.url] .filter(Boolean) .join( ); await $.auth.set({ screenName }); await $.http.get(/admin/pages/); };它会请求/admin/site/读取站点标题与地址拼成连接的显示名称screenName再请求/admin/pages/确认管理接口可用。两个请求都成功连接才会被判定为有效之后每次校验is-still-verified.js会重跑同一套验证。New Post Published 触发器的实现拆解该触发器的完整实现在 packages/backend/src/apps/ghost/triggers/new-post-published/index.js通过defineTrigger声明核心信息如下export default defineTrigger({ name: New post published, key: newPostPublished, type: webhook, description: Triggers when a new post is published., ... });name界面展示名「New post published」key内部唯一标识newPostPublishedtypewebhook说明该触发器由外部事件驱动description与文档一致——当一篇新文章发布时触发。registerHook如何订阅 Ghost 的 post.published 事件Webhook 类型触发器的关键步骤是「注册回调」。当你在 Automatisch 中为一个流程启用该触发器时会执行registerHookasync registerHook($) { const payload { webhooks: [ { event: post.published, target_url: $.webhookUrl, name: Flow ID: ${$.flow.id}, }, ], }; const response await $.http.post(/admin/webhooks/, payload); const id response.data.webhooks[0].id; await $.flow.setRemoteWebhookId(id); }其工作流程是向 Ghost Admin API 的/admin/webhooks/端点 POST 一条 webhook 订阅订阅的event为post.published文章发布事件target_url指向 Automatisch 为该流程动态生成的$.webhookUrl以Flow ID: 流程ID作为 webhook 名称便于在 Ghost 后台识别来源将 Ghost 返回的 webhook 记录 ID 保存为remoteWebhookId供后续注销时使用。run收到事件后如何产出数据当 Ghost 命中post.published并回调 Webhook 地址时触发器的run方法会被执行async run($) { const dataItem { raw: $.request.body, meta: { internalId: Crypto.randomUUID(), }, }; $.pushTriggerItem(dataItem); }它把 Ghost 推送的请求体$.request.body即新文章的结构化数据包装成一条触发数据项并生成一个随机的internalId用于执行记录去重/追踪随后通过$.pushTriggerItem推入流程引擎。后续所有步骤例如把新文章标题同步到其他应用都可以引用这批输出数据。testRun无事件时如何测试为了在没有真实新文章时也能验证流程testRun会复用最近一次执行步骤的数据async testRun($) { const lastExecutionStep await $.getLastExecutionStep(); if (!isEmpty(lastExecutionStep?.dataOut)) { $.pushTriggerItem({ raw: lastExecutionStep.dataOut, meta: { internalId: }, }); } }也就是说只要流程此前成功跑过一次测试运行就能直接取用上次的dataOut作为模拟输入若从未执行过则测试不会产生数据项。unregisterHook停用流程时的清理当你停用或删除该流程时unregisterHook会调用 Ghost 删除对应的远端 webhookasync unregisterHook($) { await $.http.delete(/admin/webhooks/${$.flow.remoteWebhookId}/); }这一对「注册/注销」保证了远程订阅与流程生命周期严格同步避免 Ghost 后台残留失效的 webhook。在 Automatisch 中配置使用该触发器把以上原理落到实际操作上推荐步骤如下进入 Automatisch 的Flows页面创建一个新流程在「Choose an app and event」中选择Ghost事件event列表中选择New post published在连接connection下拉中选择之前创建的 Ghost 连接若尚未创建可在该步骤内直接跳转创建保存并启用流程——启用时 Automatisch 会向你的 Ghost 实例注册post.published的 webhook到 Ghost 后台发布一篇文章返回 Automatisch 的Executions页面查看本次执行触发器的输出即为该文章的数据负载可以再串联任意后续步骤如发送通知、写入其他应用并在流程中使用触发器输出的字段。需要留意触发器的输出结构直接取决于 Ghost 推送的post.published事件负载包括文章标题、URL、作者等元数据具体字段以你的 Ghost 版本实际返回为准。若你的流程曾执行成功也可以在编辑器中点击测试test run来复用最近一次数据预览输出结构。常见问题与排查方向连接验证失败确认Instance URL是站点根地址不要带上/ghost/api且Admin API Key是完整的{id}:{secret}形式验证逻辑会依次请求/admin/site/与/admin/pages/任一失败都会导致校验不通过。发布文章后流程未触发进入 Ghost 后台的Integrations → 对应自定义集成检查是否存在名为Flow ID: xxx的 webhook并核对target_url是否与 Automatisch 为该流程生成的回调地址一致若不一致尝试停用再重新启用流程强制重新注册。停用流程后 Ghost 后台仍有残留 webhook正常停用流程会调用unregisterHook删除远端记录若发现残留通常是流程被强制中断所致可在 Ghost 后台手动删除该 webhook或重新启用再停用一次以触发清理逻辑。鉴权相关报错401Admin API Key 生成的 JWT 有效期为 1 小时且audience固定为/admin/若你的 Ghost 实例版本较旧或开启了自定义鉴权策略需要确认其与 HS256/JWT 方案兼容。小结Automatisch 的 Ghost 应用虽小却是一个结构非常完整的 Webhook 触发器示例通过setBaseUrl/addAuthHeader两个钩子完成 API 地址与 JWT 鉴权通过registerHook订阅post.published事件再由run消费回调负载、unregisterHook做生命周期清理。掌握「New post published」这一个触发器的接入与排查也就同时理解了 Automatisch 中所有 Webhook 类触发器如各类「当新内容发布/创建时」场景的统一工作模型。如果你想深入了解触发器的通用定义规范可以继续阅读 define-trigger.js 与 define-app.js而 Ghost 应用的连接接入细节可回看 connection.md 与 auth/index.js。【免费下载链接】automatischThe open source Zapier alternative. Build workflow automation without spending time and money.项目地址: https://gitcode.com/GitHub_Trending/au/automatisch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Automatisch 中 Ghost 触发器实战：New Post Published 的接入原理与流程配置
Automatisch 中 Ghost 触发器实战New Post Published 的接入原理与流程配置【免费下载链接】automatischThe open source Zapier alternative. Build workflow automation without spending time and money.项目地址: https://gitcode.com/GitHub_Trending/au/automatisch本文围绕 Automatisch 对 Ghost开源博客平台的官方触发器「New post published」展开讲解该 Webhook 触发器的能力边界、连接配置、底层实现原理以及如何在一个自动化流程中订阅「新文章发布」事件并消费其数据负载。读完本文你将掌握在 Automatisch 中为 Ghost 创建连接、配置流程、启用/停用该触发器的完整方法并理解其背后基于 Ghost Admin API Webhook 的事件订阅机制。Ghost 触发器一览当前版本只有一个事件在 Automatisch 的 Ghost 应用中官方目前提供的触发器记录在 packages/docs/pages/apps/ghost/triggers.md 中内容非常聚焦——当前仅有一个触发器名称触发条件New post published当一篇新文章post发布时触发该触发器的类型为webhook而非轮询意味着 Automatisch 不会定时去抓取 Ghost 的接口而是由 Ghost 在文章发布事件发生时主动把数据推送到 Automatisch 生成的 Webhook 地址上。这在事件及时性、请求开销两方面都优于轮询方案。在源码层面触发器注册于 packages/backend/src/apps/ghost/triggers/index.jsimport newPostPublished from ./new-post-published/index.js; export default [newPostPublished];而应用app本身的声明位于 packages/backend/src/apps/ghost/index.jsexport default defineApp({ name: Ghost, key: ghost, baseUrl: https://ghost.org, apiBaseUrl: , iconUrl: {BASE_URL}/apps/ghost/assets/favicon.svg, authDocUrl: {DOCS_URL}/apps/ghost/connection, primaryColor: #15171A, supportsConnections: true, beforeRequest: [setBaseUrl, addAuthHeader], auth, triggers, });从这里可以看到 Ghost 应用的几个关键事实它通过supportsConnections: true支持连接凭据管理所有出站请求都会经过setBaseUrl与addAuthHeader两个前置钩子统一处理 URL 与鉴权头。前置条件先建立 Ghost 连接在使用「New post published」触发器之前必须先在 Automatisch 中创建一条 Ghost 连接。官方操作指引记录在 packages/docs/pages/apps/ghost/connection.md步骤如下登录你的 Ghost 后台Ghost Admin panel。点击Integrations集成按钮。点击Add custom integration添加自定义集成创建一个 Admin API Key管理 API 密钥。在 Automatisch 的Admin API Key字段中填入该密钥。在 Automatisch 的Instance URL实例地址字段中填入你的 Ghost API URL例如https://your-blog.example.com。点击Submit提交。连接建立成功后即可在流程中开始使用该连接。两个必填字段的源码视角连接表单定义在 packages/backend/src/apps/ghost/auth/index.js包含两个required: true的字段Instance URLinstanceUrlstring你的 Ghost 站点地址Admin API KeyapiKeystring由 Ghost 自定义集成生成的 Admin API 密钥。这两个字段的实际作用在请求钩子中体现得淋漓尽致。Instance URL 如何变成 API 地址packages/backend/src/apps/ghost/common/set-base-url.js 会在每次请求发出前拼接基础 URLconst setBaseUrl ($, requestConfig) { const instanceUrl $.auth.data.instanceUrl; if (instanceUrl) { requestConfig.baseURL ${instanceUrl}/ghost/api; } return requestConfig; };即最终所有 API 请求都会被定向到instanceUrl/ghost/api之下配合后续的/admin/webhooks/、/admin/site/等路径使用。Admin API Key 如何完成鉴权Ghost 的 Admin API Key 形如{id}:{secret}。鉴权逻辑位于 packages/backend/src/apps/ghost/common/add-auth-header.jsconst addAuthHeader ($, requestConfig) { const key $.auth.data?.apiKey; if (key) { const [id, secret] key.split(:); const token jwt.sign({}, Buffer.from(secret, hex), { keyid: id, algorithm: HS256, expiresIn: 1h, audience: /admin/, }); requestConfig.headers.Authorization Ghost ${token}; } return requestConfig; };可以看到Automatisch 用:切分密钥的id与secret以 HS256 算法签发一个1 小时有效、audience为/admin/的 JWT并以Authorization: Ghost token的形式附加到请求头。这完全遵循 Ghost Admin API 的官方鉴权规范因此任何符合该规范的 Ghost 实例包括自托管 Ghost都能接入。连接验证的底层逻辑提交连接时Automatisch 会调用 packages/backend/src/apps/ghost/auth/verify-credentials.js 做连通性校验const verifyCredentials async ($) { const site await $.http.get(/admin/site/); const screenName [site.data.site.title, site.data.site.url] .filter(Boolean) .join( ); await $.auth.set({ screenName }); await $.http.get(/admin/pages/); };它会请求/admin/site/读取站点标题与地址拼成连接的显示名称screenName再请求/admin/pages/确认管理接口可用。两个请求都成功连接才会被判定为有效之后每次校验is-still-verified.js会重跑同一套验证。New Post Published 触发器的实现拆解该触发器的完整实现在 packages/backend/src/apps/ghost/triggers/new-post-published/index.js通过defineTrigger声明核心信息如下export default defineTrigger({ name: New post published, key: newPostPublished, type: webhook, description: Triggers when a new post is published., ... });name界面展示名「New post published」key内部唯一标识newPostPublishedtypewebhook说明该触发器由外部事件驱动description与文档一致——当一篇新文章发布时触发。registerHook如何订阅 Ghost 的 post.published 事件Webhook 类型触发器的关键步骤是「注册回调」。当你在 Automatisch 中为一个流程启用该触发器时会执行registerHookasync registerHook($) { const payload { webhooks: [ { event: post.published, target_url: $.webhookUrl, name: Flow ID: ${$.flow.id}, }, ], }; const response await $.http.post(/admin/webhooks/, payload); const id response.data.webhooks[0].id; await $.flow.setRemoteWebhookId(id); }其工作流程是向 Ghost Admin API 的/admin/webhooks/端点 POST 一条 webhook 订阅订阅的event为post.published文章发布事件target_url指向 Automatisch 为该流程动态生成的$.webhookUrl以Flow ID: 流程ID作为 webhook 名称便于在 Ghost 后台识别来源将 Ghost 返回的 webhook 记录 ID 保存为remoteWebhookId供后续注销时使用。run收到事件后如何产出数据当 Ghost 命中post.published并回调 Webhook 地址时触发器的run方法会被执行async run($) { const dataItem { raw: $.request.body, meta: { internalId: Crypto.randomUUID(), }, }; $.pushTriggerItem(dataItem); }它把 Ghost 推送的请求体$.request.body即新文章的结构化数据包装成一条触发数据项并生成一个随机的internalId用于执行记录去重/追踪随后通过$.pushTriggerItem推入流程引擎。后续所有步骤例如把新文章标题同步到其他应用都可以引用这批输出数据。testRun无事件时如何测试为了在没有真实新文章时也能验证流程testRun会复用最近一次执行步骤的数据async testRun($) { const lastExecutionStep await $.getLastExecutionStep(); if (!isEmpty(lastExecutionStep?.dataOut)) { $.pushTriggerItem({ raw: lastExecutionStep.dataOut, meta: { internalId: }, }); } }也就是说只要流程此前成功跑过一次测试运行就能直接取用上次的dataOut作为模拟输入若从未执行过则测试不会产生数据项。unregisterHook停用流程时的清理当你停用或删除该流程时unregisterHook会调用 Ghost 删除对应的远端 webhookasync unregisterHook($) { await $.http.delete(/admin/webhooks/${$.flow.remoteWebhookId}/); }这一对「注册/注销」保证了远程订阅与流程生命周期严格同步避免 Ghost 后台残留失效的 webhook。在 Automatisch 中配置使用该触发器把以上原理落到实际操作上推荐步骤如下进入 Automatisch 的Flows页面创建一个新流程在「Choose an app and event」中选择Ghost事件event列表中选择New post published在连接connection下拉中选择之前创建的 Ghost 连接若尚未创建可在该步骤内直接跳转创建保存并启用流程——启用时 Automatisch 会向你的 Ghost 实例注册post.published的 webhook到 Ghost 后台发布一篇文章返回 Automatisch 的Executions页面查看本次执行触发器的输出即为该文章的数据负载可以再串联任意后续步骤如发送通知、写入其他应用并在流程中使用触发器输出的字段。需要留意触发器的输出结构直接取决于 Ghost 推送的post.published事件负载包括文章标题、URL、作者等元数据具体字段以你的 Ghost 版本实际返回为准。若你的流程曾执行成功也可以在编辑器中点击测试test run来复用最近一次数据预览输出结构。常见问题与排查方向连接验证失败确认Instance URL是站点根地址不要带上/ghost/api且Admin API Key是完整的{id}:{secret}形式验证逻辑会依次请求/admin/site/与/admin/pages/任一失败都会导致校验不通过。发布文章后流程未触发进入 Ghost 后台的Integrations → 对应自定义集成检查是否存在名为Flow ID: xxx的 webhook并核对target_url是否与 Automatisch 为该流程生成的回调地址一致若不一致尝试停用再重新启用流程强制重新注册。停用流程后 Ghost 后台仍有残留 webhook正常停用流程会调用unregisterHook删除远端记录若发现残留通常是流程被强制中断所致可在 Ghost 后台手动删除该 webhook或重新启用再停用一次以触发清理逻辑。鉴权相关报错401Admin API Key 生成的 JWT 有效期为 1 小时且audience固定为/admin/若你的 Ghost 实例版本较旧或开启了自定义鉴权策略需要确认其与 HS256/JWT 方案兼容。小结Automatisch 的 Ghost 应用虽小却是一个结构非常完整的 Webhook 触发器示例通过setBaseUrl/addAuthHeader两个钩子完成 API 地址与 JWT 鉴权通过registerHook订阅post.published事件再由run消费回调负载、unregisterHook做生命周期清理。掌握「New post published」这一个触发器的接入与排查也就同时理解了 Automatisch 中所有 Webhook 类触发器如各类「当新内容发布/创建时」场景的统一工作模型。如果你想深入了解触发器的通用定义规范可以继续阅读 define-trigger.js 与 define-app.js而 Ghost 应用的连接接入细节可回看 connection.md 与 auth/index.js。【免费下载链接】automatischThe open source Zapier alternative. Build workflow automation without spending time and money.项目地址: https://gitcode.com/GitHub_Trending/au/automatisch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考