El punto de conexión de la API para crear enlaces de invitación se ha movido a /invites.json

Is this related to the fact that the https://{defaultHost}/invites/link.json API stopped working today?

1 me gusta

I’m not sure - it could be? I am not familiar with this endpoint.

Well, I have got a few hundreds emails from our automation now failing. We used the endpoint https://{defaultHost}/invites/link and we started getting 404. I check the documentation and the endpoint is now reported to be https://{defaultHost}/invites/link.json (with the extra .json), but also with that change I keep getting 404.
I am not sure how to fix that. We need to generate invite links to send them through our systems. It worked beautifully until today

Also, doing a PUT to that address return BAD REQUEST, but a PUT to an unexisting address returns NOT FOUND. I am not sure if this is an hint that the endpoint is there and it is just not working

Maybe I should specify that I have an instance of Discourse hosted by you at https://d.strumenta.community/

That API endpoint was moved to https://{defaultHost}/invites.json as we consolidated the email and link invites.

2 Me gusta

Ok, then I think the documentation is not up-to-date

Does this endpoint generates an invite link, but does not send an email?

Because according to the documentation the difference betweek /invites.json and and /invites/link.json is the sending of the email

1 me gusta

Also, a post to /invites.json returns BAD REQUEST for me → my bad, I should use " and not '

With the correction, I get an answered telling the user was emailed, and I would like to prevent that:

It would be useful to have a notification when API changes and get access to the current documentation, otherwise stuff breaks all of a sudden and one cannot fix it…

Adding this here, just for visibility:

$ 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":[]}%                             

I will be updating our API documentation. Thank you for bringing that to my attention and sorry for the inconvenience.

7 Me gusta

It would be nice if create returned the existing invite link instead of throwing an error if it’s from the same user. The 422 error response is pretty generic, it took me ages to figure out why my tests were failing.

1 me gusta

Added a PR for retrieving an existing invite by email address: FEATURE: Retrieve an existing link only invite by jessicah · Pull Request #12575 · discourse/discourse · GitHub

1 me gusta

I found an undocumented flag skip_email that prevents the email being sent so you can just grab the link. Pass it in the body with the email and you should be good!

    {
        "email": "someone@test.com",
        "skip_email": "true"
    }

I did some brief testing and it’s worth noting that if you use it to generate an email link, then you can’t go back and use it to send an email automatically - emailed always returns false once skip_email is used.

1 me gusta

¿Hay alguna razón por la que invites/retrieve no esté en la documentación bajo Discourse API Docs? ¿O me estoy perdiendo algo?

Quiero invitar direcciones de correo electrónico que existen en una base de datos externa, solo si a) ya tienen una cuenta y b) si aún no han sido invitados (este proceso se ejecutará periódicamente y no quiero enviar spam a las personas que no han respondido a su invitación lo suficientemente rápido). invites/retrieve.json parece ser la forma correcta de verificar b) según lo que parece estar en el commit.

2 Me gusta

Es probable que sea solo una omisión que falta en la documentación de la API, trabajaré para que se añada.

2 Me gusta

Estaría bien si estos fueran generados por, o al menos probados contra, el núcleo actual de Discourse.

Parecería que debería haber una manera razonablemente simple (lo que probablemente signifique 2 días de trabajo y no la hora que me gustaría creer) de hacer que las especificaciones se ejecuten para probarlos. Oh, ¿o tal vez eso es lo que se supone que hace https://redocly.com/?

Lo que realmente sería útil para mi caso de uso es una forma de recuperar todas las invitaciones enviadas por todos los usuarios. Si “por todos los usuarios” es el punto de inflexión, estaría bien para mi caso de uso recuperar todas las invitaciones (independientemente de su estado).

Con este método me veo obligado a sondear cada posibilidad, que podrían ser 1000 direcciones de correo electrónico cuando probablemente solo hay unas pocas en la tabla.

How to get a password from database? - #3 by pfaffman indica que la base de datos no se expone por defecto, por lo que usar código para acceder a la base de datos desde un proceso externo no es factible directamente, al menos no con mi implementación actual, y quizás tampoco sería una buena idea exponer el puerto de la base de datos en ningún caso.

Estoy tratando de automatizar las invitaciones y la pertenencia a grupos para direcciones de correo electrónico en una base de datos externa.

Y dos veces se refirió al complemento Data Explorer, que también es la respuesta aquí, pero tal vez necesites saber que puedes Run Data Explorer queries with the Discourse API

ah sí, ese era el punto clave que me faltaba, gracias por la indicación

1 me gusta