Here are just a few thoughts that came to me.
An admin-privileged app could get a list of all unconfirmed users pretty easily. Just call
GET /api/v2/system/user?filter=is_active%3Dfalse&fields=id%2Ccreated_date%2Cemail%2Cconfirm_code
This will return an array of unconfirmed users with all the information I could think of needing. (You could add to the &fields=
list as needed.) For example:
{
"resource": [
{
"id": 3,
"created_date": "2014-01-17 19:34:05",
"email": "drdre@hotmail.com",
"confirm_code": "blahblahblah"
},
{
"id": 27,
"created_date": "2015-03-04 00:54:36",
"email": "rowsdower@compuserve.com",
"confirm_code": "yaarpyaarpyaarp"
},
{
"id": 43,
"created_date": "2015-10-15 09:04:24",
"email": "rivertam@gmail.com",
"confirm_code": "blerghblerghblergh"
}
]
}
Now you could do several things with this information: remove all unconfirmed users, remove all unconfirmed users with a created_date
over 30 days ago, send a reminder email with confirmation code to all users with created_date
over 60 days ago, etc.
You could make date calculations within the app and then send DELETE /api/v2/system/user?ids=29%2C37%2C59
where the list of ids is made of just those that match your desired age calculation. Or, you could make the API do the work and only GET users with created_date more than 30 days ago. Like this:
GET /api/v2/system/user?filter=is_active%3Dfalse%20and%20created_date%3Ctimestampadd(day%2C-30%2Cnow())&fields=id%2Ccreated_date%2Cemail%2Cconfirm_code
The above would return you only the two unconfirmed users from above that are more than 30 days old:
{
"resource": [
{
"id": 3,
"created_date": "2014-01-17 19:34:05",
"email": "drdre@hotmail.com",
"confirm_code": "blahblahblah"
},
{
"id": 27,
"created_date": "2015-03-04 00:54:36",
"email": "rowsdower@compuserve.com",
"confirm_code": "yaarpyaarpyaarp"
}
]
}
Now if you take the harsh approach I mentioned above, you could just DELETE /api/v2/system/user?ids=3%2C27
and expect them to re-register themselves with the same email. But perhaps you’d rather send them a new confirmation email, like what happens when an admin goes back into the admin console and clicks “Send Invite” again. I captured the API call from the “Send Invite” button using my browser console, and it’s just as simple as this:
PATCH /api/v2/system/user/3?send_invite=true
So to send invites for more than one user, say, all of the ids returned from the most recent GET query above, you would
PATCH /api/v2/system/user?send_invite=true
with a payload of {"resource":[ {"id": 3},{"id": 27}]}
. The API will return the ids for which the PATCH was successful. The sent invitations will adhere to whatever email template you have selected for invitations, which ought to already have their confirmation code included.
The last method I came up with was that your admin-privileged app could also initiate a different email entirely. You’ve already retrieved the users’ emails and confirm_codes, so you could just POST to /api/v2/emailservice
whatever email you’d like (such as one with a subject line of “You haven’t yet confirmed your membership!” or something like that).