这是否与 https://{defaultHost}/invites/link.json API 今天停止工作有关？
我不太确定——也许吧？我不熟悉这个端点。
嗯，我们的自动化系统现在收到了数百封报错邮件。我们之前使用的端点是 https://{defaultHost}/invites/link，但开始返回 404 错误。我查阅了文档，发现该端点现在应改为 https://{defaultHost}/invites/link.json（多了 .json 后缀），但即使做了这个修改，我仍然收到 404 错误。
我不确定该如何解决这个问题。我们需要生成邀请链接并通过我们的系统发送。直到今天之前，一切运行得非常顺利。
另外，向该地址发送 PUT 请求会返回 BAD REQUEST，而向一个不存在的地址发送 PUT 请求则返回 NOT FOUND。我不确定这是否暗示该端点确实存在，只是无法正常工作。
也许我应该说明一下，我在 https://d.strumenta.community/ 托管了一个 Discourse 实例。
该 API 端点已移至 https://{defaultHost}/invites.json，因为我们整合了邮件邀请和链接邀请。
2 个赞
好的，那么我认为文档可能不是最新的。
这个端点是否生成邀请链接，但不发送电子邮件？
因为根据文档，/invites.json 和 /invites/link.json 之间的区别在于是否发送电子邮件。
1 个赞
另外，向 /invites.json 发布请求时，我收到了“错误请求”的响应 → 是我的问题，我应该使用 " 而不是 ''
修正后，我收到了一条回复，告知用户已收到邮件，而我希望避免这种情况：
如果在 API 发生变更时能收到通知，并提供当前文档的访问权限，将会很有帮助。否则，某些功能会突然失效，导致无法及时修复……
在此添加此内容，仅用于提高可见性：
$ curl 'http://localhost:3000/invites.json' -X 'POST' \
-H "Api-Key: d5fc02c5f4efaafacc82e4ff3410ae283d1c5da68ac43430d5133aaf4785593f" \
-H "Api-Username: dan" \
-H "Content-Type: application/json" \
-d "{\"max_redemptions_allowed\":5}"
{"id":18,"link":"http://localhost:3000/invites/6f524dba4ced35ecae709a8614db3b05","redemption_count":0,"max_redemptions_allowed":5,"custom_message":null,"updated_at":"2021-03-10T15:44:44.259Z","expires_at":"2021-04-09T15:44:44.258Z","expired":false,"topics":[],"groups":[]}%
我将更新我们的 API 文档。感谢您指出这一点，对于造成的不便深表歉意。
7 个赞
如果 create 在链接来自同一用户时返回现有的邀请链接而不是抛出错误，那就太好了。422 错误响应非常笼统，我花了好长时间才弄清楚为什么我的测试会失败。
1 个赞
已提交一个拉取请求，用于通过电子邮件地址检索现有邀请：FEATURE: Retrieve an existing link only invite by jessicah · Pull Request #12575 · discourse/discourse · GitHub
1 个赞
我发现了一个未文档化的标志 skip_email，它可以阻止邮件发送，这样你就可以直接获取链接。只需在请求体中将其与邮箱地址一起传递即可，一切正常！
{
"email": "someone@test.com",
"skip_email": "true"
}
我进行了一些简要测试，需要注意的是，如果你用它来生成邮件链接，那么之后就无法再将其用于自动发送邮件了——一旦使用了 skip_email，emailed 将始终返回 false。
1 个赞
在 Discourse API Docs 下的文档中，是否有任何关于 invites/retrieve 的原因未被提及？或者是我错过了什么。
我想邀请外部数据库中存在的电子邮件地址，前提是 a) 他们还没有账户，并且 b) 他们还没有被邀请（此过程会定期运行，我不想对那些没有足够快回复邀请的人进行垃圾邮件轰炸）。根据提交中的内容来看，invites/retrieve.json 似乎是确定 b) 的正确方法。
2 个赞
这很可能只是 API 文档中遗漏的一个疏忽，我会努力将其添加上去。
3 个赞
如果这些（文档）是根据当前的 Discourse 核心生成的，或者至少是经过当前 Discourse 核心测试的，那就太好了。
看起来应该有一种相当简单的方法（这可能意味着需要两天的工作，而不是我希望相信的 1 小时！）来运行规范来测试它们。哦，或者也许这就是 https://redocly.com/ 的作用？
对我的用例来说，真正有帮助的是一种检索所有用户邀请的所有邀请的方法。如果“所有用户”是限制点，那么检索所有邀请（无论状态如何）对我的用例来说也可以接受。
使用此方法，我被迫轮询每一种可能性，这可能是 1000 个电子邮件地址，而表中可能只有少数几个。
How to get a password from database? - #3 by pfaffman 表明数据库默认情况下不暴露，因此使用代码从外部进程访问数据库是不可行的，至少在我目前的实现中是这样——而且无论如何暴露数据库端口可能也不是一个好主意。
我正试图在外部数据库中自动化电子邮件地址的邀请和组成员资格。
并且两次都提到了数据资源管理器插件（data explorer plugin），这在这里也是答案，但也许你需要知道你可以 Run Data Explorer queries with the Discourse API
啊，是的，这正是我遗漏的关键点——感谢您的指点
1 个赞