Topics

Some initial questions...


James Milligan
 
Edited

- Where can API keys be found or generated? Since the API is still in alpha, is it just a case that they are unavailable right now?
 
- Are there plans to support custom fields that can only be edited by mods/owners? I see the moderator notes field, but in the future it would be good to have distinct named fields that can be referenced by calling applications (think external identifiers and so on).
 
In my case, with our membership system, I can invite or add a user to the group with a known email address, but if they change their email address later on in Groups.IO I lose the only 'link' I have on a technical level with our membership system. Storing their membership number against their account (which won't change) will allow me to pivot around those instead of email addresses, and remove them once their membership lapses. Which leads me onto...
 
- Are there plans to allow searching for members (aside from having to fetch all members and search within the results)? If custom fields are supported, I'd like to be able to search based on these as well.
 
On a separate but related note, one approach that could work well for getting members without searching or knowing their internal ID is through allowing reference by a hashed version of the user's email address (including aliased addresses). If a member exists that has that email address on their profile their object is returned. Mailchimp does something similar which work well enough.
 
Thanks in advance!
 
Kind regards,

James Milligan
Need to integrate with the Groups.io API in Java? Check out the Groups.io API Java client


 

Hi James,

On Tue, Aug 8, 2017 at 11:00 AM, James Milligan <james@...> wrote:
- Where can API keys be found or generated? Since the API is still in alpha, is it just a case that they are unavailable right now?

I will get you a demo API key off-line. 

 
- Are there plans to support custom fields that can only be edited by mods/owners? I see the moderator notes field, but in the future it would be good to have distinct named fields that can be referenced by calling applications (think external identifiers and so on).

I'd like to have something like that, but it will have to wait, and it may be a part of a future feature where owners can set up questionnaires for their users. In the mean time, moderator_notes is probably your best bet.
 
In my case, with our membership system, I can invite or add a user to the group with a known email address, but if they change their email address later on in Groups.IO I lose the only 'link' I have on a technical level with our membership system. Storing their membership number against their account (which won't change) will allow me to pivot around those instead of email addresses, and remove them once their membership lapses. Which leads me onto...

- Are there plans to allow searching for members (aside from having to fetch all members and search within the results)? If custom fields are supported, I'd like to be able to search based on these as well.

I will add a search method. Object IDs do not change, so that'd be a good way to reference members.

Also, I've just pushed a bunch of updates to the API docs, including a section talking about versioning. Please let me know if you have questions.

Thanks,
Mark


James Milligan
 

On Thu, Aug 10, 2017 at 12:18 pm, Mark Fletcher wrote:
I will get you a demo API key off-line.
Received, thanks.
I'd like to have something like that, but it will have to wait, and it may be a part of a future feature where owners can set up questionnaires for their users. In the mean time, moderator_notes is probably your best bet.
OK. Our mods wouldn't be used to using that section for notes on members so it should be easy to store some structured data in there for now without much risk.
I will add a search method.
Great :)
Object IDs do not change, so that'd be a good way to reference members.
OK, although just thinking about this a bit more for my particular case I'm not going to have the object ID at the right point depending on how the member is being invited/added. I'm unfamiliar with the direct add functionality at the moment - is it the case that when a user is 'direct add'ed to a group via the web UI, a stub user account is created? If so, with the API, as long as I can get that object ID (or even the full user object) in the response to a 'direct add' API call that could work at least for direct add scenarios (I assume for more traditional invite scenarios the user isn't created until they accept the invite?)

Also, I've just pushed a bunch of updates to the API docs, including a section talking about versioning. Please let me know if you have questions
Looks good especially the versioning bit, however I feel it's inaccurate to state that "changing the length or format of object IDs or other opaque strings; this includes adding or removing fixed prefixes" are backwards-compatible. They might be from an API perspective, but if external systems are going to be storing these IDs they mustn't change - ideally at all, but if they must then it should be against a specific API version.

It would be nice if more of the error responses used their related HTTP codes - 401/unauthenticated (the 'real' meaning), 403/unauthorized, 429/rate limit and so on rather than bundling them into a custom error object - avoids deserialising them when a simple HTTP code check would suffice.