Use case of API action in Custom Wizard

Support Discourse Custom Wizard
1

Continuing from [1], since the OP did not and my query is substantially similar.

Objective:

  • Self-hosted Discourse with donations (very low cost, e.g. $0.9/mo)
  • Donations are made completely externally (crypto token). I just want to receive enough funds to recover my costs and give non-contributing community less. No accounting, no refunds, no invoices, min dev, min maintenance, min overhead.

Because custom payments tend to be complicated and easy to break, I want to describe how this minimal approach could work for me.

  • Default access is Category Previews [2].
    • Visitors who don’t want to register can still get something out of the site (category preview).
    • Members who do register (but don’t donate) get the same access - no way to comment, react, etc. (objective: KISS). If it’s possible to preview posts (rather than just categories), that would be nice to motivate them to register, but it’s not required. Simplicity first.
  • API action makes a request with 4 vars - reg_date, username (or some unique ID?), dst_addr, and membership_level - to an external script or API in the same Docker Compose (I can take care of this - receive a request, return a JSON response)
    • On the first run the optional “donation” (destination, not source) address" (dst_addr) field in user’s Profile is empty and membership_level=guest. My external script/API sees dst_addr is null so I know at this time I just need to return a unique dst_addr for API action to store it in user’s Profile (64 byte string, like an email address but no validation needed and it cannot be edited by the user - see [4]). The key point here is each user donates to a different dst_addr, and there’s no need to ever edit or remove it from User’s Profile (KISS). It may be nice to have a Hide On/Off for this (so that the user can choose to show dst_addr they use), but this isn’t very important
    • If I can run the same API action (or create another) daily:
      • if dst_addr is null (e.g. maybe previous runs failed), return a new dst_addr which the Plugin populates in user’s Profile
      • if dst_addr is not empty, I check for transfers to dst_addr within last 30 days which is very simple
        • If a tx with the required minimum donation amount has been found, return membership_level=patron to the Plugin
        • if not, return return membership_level=guest, which results in user’s membership level resetting to Guest. They still have their Discourse account, can view dst_addr and donate at any time to regain full access at their convenience, but their access is the same as Guest who hasn’t logged in (or it can be logged_in_guest with the same features as guest, if it can’t be the same due to the way the Plugin works)

I don’t know if API actions can be created to run such “batch jobs”, or something like [3] could be done from the CLI every 12 hours, for example, in which case I’d need only the initial API action (to create/populate dst_addr, whereas the rest would be done from an OS scheduled-script or a separate “daily” API action in the Plugin that loops over all registered users).

I don’t expect to have thousands of members (not even 200) so I think this is workable and should be very reliable because all checks can fail multiple times and still not impact user’s experience.

I apologize if I “reinvented the wheel” (or even invented a broken wheel) but I haven’t used your plugin, so the above is just a sketch that could help you understand what I want. You can tell me how something like this could be best done with existing Plugin features.

Does this make sense? Would that be something that could be done without changes to the Plugin?
I don’t mind a different approach that meets my objectives and doesn’t require a dev effort on your side.

[1] Action Settings - #54 by angus
[2] Tighter integration of account-creation and subscriptions? - #3 by Moin - Feature - Discourse Meta
[3] Batch operations on multiple users - #6 by riking - Feature - Discourse Meta
[4] Example: 0x1111111111111111111111111111111111111111111111111111111111111111