核心用法
n8n-api 是一个纯文档型技能，旨在指导用户通过 n8n 公共 REST API 实现工作流自动化平台的编程化管理。该技能覆盖了工作流全生命周期操作：包括工作流的列表查询、详情获取、激活/停用（发布/下线）、创建与删除；执行记录的检索、状态筛选与失败重试；以及 Webhook 触发、健康检查仪表盘等运维场景。用户需配置 N8N_API_BASE_URL 和 N8N_API_KEY 环境变量，通过标准 HTTP Header 认证后即可调用 API。技能同时兼容 n8n Cloud 托管版与自托管实例，并提供 curl 命令示例与 jq 数据处理技巧，降低 API 使用门槛。
显著优点
1. 零代码执行风险：纯文档型设计，无脚本文件或可执行代码，所有操作均需用户显式手动执行，从根本上杜绝了自动化攻击面。
2. 标准化安全实践：明确推荐使用 HTTPS 加密传输，API 密钥通过环境变量配置而非硬编码，符合企业级安全规范。
3. 运维场景覆盖全面：从日常监控（活跃工作流计数、24 小时失败统计）到故障排查（执行详情分析、节点级调试）均有成熟方案，显著提升 n8n 实例的可观测性。
4. 双模式兼容：同时支持 n8n Cloud 与自托管部署，满足不同规模团队的基础设施偏好。
潜在缺点与局限性
1. 功能受限门槛：n8n Cloud 免费试用期间无法使用公共 API，需升级付费计划，对预算敏感用户形成阻碍。
2. 无原生 SDK 封装：仅提供原始 HTTP/curl 示例，缺乏高级语言（Python/Node.js/Go）的 SDK 封装，开发者需自行处理分页、重试、错误解析等逻辑。
3. Webhook 与 API 边界混淆：文档特别指出 Webhook URL 与 API URL 体系独立、认证方式不同，新手易因概念混淆导致调试困难。
4. 执行记录保留策略依赖实例配置：历史执行数据可能因实例级保留设置被自动清理，长期审计需额外对接外部存储。
适合的目标群体
- 平台运维工程师：需要批量管理数十至数百个工作流、监控实例健康状态的 SRE 团队。
- 自动化开发者：希望将 n8n 集成至现有 CI/CD 流水线或内部运维平台的工程团队。
- 数据工程师：依赖 n8n 执行数据同步任务，需程序化触发与监控执行结果的场景。
- 多租户管理员：管理多个 n8n 项目或实例，需通过 API 实现跨环境配置同步的高级用户。
使用风险
1. 凭证泄露风险：用户可能误将 .n8n-api-config 文件提交至版本控制，或在命令行历史（bash_history）中留下 API 密钥痕迹。建议配合 .gitignore 与专用密钥管理工具（如 1Password CLI、AWS Secrets Manager）使用。
2. 生产环境误操作：API 支持工作流激活/停用、删除等高危操作，若配置错误的 N8N_API_BASE_URL（如将生产地址误填为开发地址的反向情况），可能导致业务中断。建议为不同环境使用隔离的 API 密钥并实施最小权限原则。
3. 网络可达性依赖：自托管实例若部署于内网或 VPN 后，需确保执行环境具备网络连通性；n8n Cloud 用户则需关注服务商的 API 速率限制与可用性 SLA。
4. 无内置重试与熔断：curl 示例未展示指数退避、熔断降级等生产级 HTTP 客户端模式，高并发场景下需自行实现容错逻辑。