场景导入：别再让“死数据”拖垮你的业务效率
兄弟们，咱们聊点实在的。你有没有遇到过这种场景：业务系统需要一个数据，但现有的工具给不了，或者每次都要人工导出 CSV 再上传？又或者，你写了个 Python 脚本跑数据，却苦于没有一个简单的“门把手”让其他系统能调用它？
在 N8N 大学，笔者见过太多朋友在“数据孤岛”里打转。手动操作不仅效率低，还容易出错。今天，笔者就带大家硬核实战，教你怎么用 n8n 把“死数据”变成“活服务”——搭建一个自定义的 API 接口。只需 Webhook 和 Respond to Webhook 两个节点，你就能对外提供 JSON 数据服务，让你的自动化流程瞬间拥有“后端开发”的能力。
准备工作：手里有粮，心里不慌
在开始之前，咱们得确认一下“弹药”是否充足。这套玩法对环境要求不高，但基础得有：
- n8n 环境：无论是官方 Cloud 版、Docker 本地部署，还是云服务器搭建的，只要能访问就行。
- 公网访问能力（关键）：如果你是在本地跑的 n8n，外部系统想调用你的接口，你需要做内网穿透（比如 ngrok），或者你本身就在云服务器上有公网 IP。
- 一颗爱折腾的心：API 这玩意儿，第一次通的时候最爽。
核心实操：三步打造你的专属 API
别废话，直接上手。笔者将手把手教你从零搭建一个“查询用户信息”的 API 接口。
第一步：接收请求——部署 Webhook 节点
API 的本质就是“请求-响应”。首先，我们需要一个“接收员”来把外部的请求接进来。
在画布上拖入一个 Webhook 节点。这是 n8n 的万金油节点。双击配置：
- HTTP Method：选择
POST（当然也可以选 GET，但 POST 更专业）。 - Path：自定义你的接口路径，比如
/api/get.UserInfo。
配置好后，点击右上角的“执行一次”。此时，n8n 会生成一个 Webhook URL。这就是你对外暴露的接口地址，先复制下来备用。
第二步：处理数据——模拟业务逻辑
接收到请求后，你需要返回数据。在真实场景中，这里可能是连接数据库、查询 Excel 或调用其他 API。为了演示，笔者用 Set 节点来模拟一个查询结果。
在 Webhook 后面接一个 Set 节点：
- Name：填
user_id，Value：填1001。 - 再添加一行，Name：填
status，Value：填active。
这一步的意义在于：无论外部传入什么参数，我们这里都按照固定逻辑处理数据，准备打包成 JSON。
第三步：返回结果——配置 Respond to Webhook
这是最关键的一步！很多新手在这里翻车，以为数据处理完就结束了，结果接口一直是超时。你必须显式地“回应”请求。
在 Set 节点后面，拖入 Respond to Webhook 节点。配置如下：
- Response Mode：选择
Last Node（意味着把上一步 Set 节点的数据直接返回）。 - Content Type：选择
JSON。这告诉调用方：“我给你发的是标准 JSON。 - Response Body：这里可以直接引用数据，或者手动构建 JSON 结构。为了稳妥，建议把 Set 节点的数据映射过来。
保存工作流，再次点击“执行”。
避坑指南：实战中的“拦路虎”
代码跑通了，不代表这就万事大吉了。根据 N8N 大学多年的踩坑经验，这里有两条必须提醒你的铁律：
1. 必须显式调用 Respond 节点
n8n 不像 Flask 或 Express 那样，你写了 return 就自动结束。在 n8n 里，如果你的流程最后停在 Set 节点，外部调用者会一直等到超时（通常是 300 秒）。Respond to Webhook 就是那个必须扣下的扳机。
2. 公网 URL 的拼写细节
如果你用的是 ngrok，生成的 URL 是https://abc123.ngrok.io，而 n8n Webhook 节点给的是/api/get.UserInfo。请务必拼接成完整的地址https://abc123.ngrok.io/api/get.UserInfo发送给测试工具（如 Postman），少一个斜杠都通不了。
FAQ 问答：你可能遇到的疑惑
Q1: 我的 API 返回中文字符乱码了怎么办？
A: 在 Respond to Webhook 节点中，确保 Content Type 设置为 application/json; charset=utf-8。通常 n8n 会自动处理，但显式指定是好习惯。
Q2: 我想让接口带参数验证，比如必须传 Token？
A: 在 Webhook 节点后，加一个 If 节点。判断 {{$json.headers.authorization}} 是否等于你的密钥。如果不等于，就连接一个 Respond to Webhook，将其状态码设为 401 Unauthorized。
Q3: 这个 API 的并发性能如何？
A: n8n 的单机版处理几百次请求没问题，但如果是高频商业场景，建议使用 n8n 企业版的队列模式，或者在前端加一层 Nginx 负载均衡。对于大多数内部系统，n8n 原生能力完全够用。
总结与资源
恭喜你！读完这篇教程，你已经掌握了 n8n 最核心的“变身”能力——将自动化流程封装为 API 服务。这不仅打通了数据流动的最后一公里，更是让你从一个“操作员”进化为“服务提供者”。
在 N8N 大学，我们始终相信技术应该是为人服务的。如果你在实操中遇到任何报错，欢迎随时回来翻阅我们的“避坑指南”系列。下一次，我们聊聊如何给这个 API 加上 Swagger 文档，让它看起来更专业。
