Skip to main content
Français (Canada)

ACC Sections - Q&A

Updated

Please find below the Q&A from the ACC sections - Any additional questions, please email info@2mev.com with the following email subject format "ACC Project: request name"

Please find below:

  • Questions in bold
  • Additional comments from the sections in italic
  • Feedback from the Interpodia Team in pink

You can access the ACC ADMIN GUIDE HERE

TABLE OF CONTENT

Managing members

APIs solutions

QF1: Could the Interpodia platform notify (by email) someone (configurable) for every addition / deletion to a section's member list?

It is a good head's up that that person may be looking for help soon, or may register for some trip.

We can set up 3 types of notification emails (upon request to the Interpodia support team): 

  • Transaction notification Get a copy of the receipt by email each time an order is processed from your section financial account
  • Membership purchase notification Get an email notification each time a new membership is being purchased for your section
  • Membership expiration notification Get an email when a membership expires (or will expire soon)

To request an email notification setup, please email us with the following information: 

  • Section's name
  • Email address to notify
  • Type of notification email
  • If expiration notification: number of days before/after the expiry date

QF2: Has someone look into a Single-Sign-On solution?  

It seems preferable from a user's perspective to have a single password, managed by the new Interpodia platform, and which would allow access to sections websites.

As part of its core business, Interpodia does not offer in-house, pre-built SSO solutions. In the event the sections develop a solution on their own, Interpodia will estimate the time and cost of developing a plugin option to connect to the section solution (subject to custom development cost).

QF3: How for the Interpodia API work?

Just to clarify, the API (from IMIS) currently used by section sites to import membership *is* also a PULL mechanism.  We send a request and the server responds with the membership list.  It's just that we don't have to specify a member ID.  A PUSH mechanism would be one where asynchronously, the server would send (without being requested) information to the client.  

Current identified limitations:

  1. we do not learn about new members until they try to connect.  This is a significant problem because we have a good number of people that take a membership but are not very active.  Some reasons: loyalty, or they may have the desire to participate but can't find the time, or they want to support us, or they are also part of another section but having a membership with us gives them some rebate in a climbing gym.  Whatever the cause, we want to be able to reach them when we publish a new activity or send a newsletter.  And this is all done using the section website's member list.  If 40% of our members do not connect to the section platform, then their name is not on our site list. They don't get notified of upcoming activities, they don't get a newsletter. They disengage.
  2. we do not learn about lapsed members. Our membership list (on the local web site) gets stale.  Workaround: we could run a job to periodically query the server.
  3. For the sections using automatic membership import to still be functional, I think we will need some way to get all all members.  Can't we modify the proposed API such that if, instead of passing a member ID, we pass the character "*", it sends all section membership?  Another angle: surely if we can manually import a csv file containing all users, there must be a way to automate that?  Even if it is in csv format (not as good as Json), we could probably digest that at the client side and make sense of it.

The Interpodia API is a 'membership verification' API on a per-member's basis, you send us a member unique identifier and we send back the needed information about that member currently stored on our system (upon agreement with ACC). The reason we provide a per-member verification system is based on privacy policy best practices, as the member would have to create an account/login on the section system for their information to get through, and by doing so get the opportunity to confirm they're willing to get their data transferred.

About the identified limitations: 

1- Section admins will have access to their list of members through the Interpodia-2M platform, and can also connect their list of members to MailChimp via API to create their newsletters mailing list with ease

2- Our API response would include the membership expiry date, meaning that you would be able to store that information on your website and use it accordingly. Alternatively, from your 2M dashboard, you'll have access, in real time, to the list of expired members

 3- That would require further discussion and feedback from the Interpodia development team (any additional development on our side outside of the existing API scope would be subject to custom development) 

QF6: The member API (from Interpodia) says that the request may have a comma-separated list of member numbers For how many members max does it work? 

There are no limits per se, but there is a size limit for the request parameters.

QF7: Is the member API scoped to a single section or I can ask to verify a member ID from any section?

The same member API can be used for multiple sections

QF8: Does the member API always return the latest state from the database?  If a user just subscribed to a membership and 10 seconds later we query for the data, the API will return that he owns a membership?  

Hopefully we avoid things like "it takes 24 hours for the membership to be reflected in the database"

The member API returns live data

QF9: Just to be clear on the syntax of a member ID, it is not a number, right?  It is a string, like 123456-2?  Does it always contain a "dash"?  Can a membership ID be "123456-" without a number after?  Could there be 2 digits after the dash (assuming a large family)? 

The member API matches on a string, so yes the string could include a dash in it. 

QF12: what happens if, in the comma-separated member IDs, I provide one member number which is invalid (has no associated member)?  Is the whole request failed?  If not, how is the response formatted?

An empty response for this member will be returned as no matching member has been found. 

QF4: Could the API also return the member address and phone number?

 We use that to publish our membership list.

Technically speaking, yes. Then, it's a matter of getting the proper agreement in place with ACC and making sure that the appropriate data-sharing disclaimers are in place for the members registering. 

QF10: is my understanding right that from the server response to the member API, I will be able to tell whether the user has a membership with Ottawa, with Calgary, whether he has a family or adult membership, whether he has bought the FQME option?

This is correct

QF11: What does the member API return if I query for a lapsed member?  I mean a member which no longer has any valid membership.  Do I get a response but the "list of valid memberships" is empty?

That will depend on how we will have set it up. But we would either return:

- nothing/null

- member information including the memberships status and expiry date

QF5: Do you see a security problem in the fact that connected members in our Outaouais website can access the Outaouais member list and see other members phone numbers and email? 

This is used to organize trips and coordinate.  After all, a club is not a club if we cannot reach each other.

That is for your legal teams to advise on, if you wanted to leave the members the choice to accept or not to be displayed in a member's directory (public or with restricted access) - which, in my opinion, is the appropriate way to go - note that Interpodia-2M integrated has member's directory (membership lookup page) setup option allowing: 

  • ACC or the section to decide the information being displayed
  • ACC or the section to decide what type of membership is being displayed
  • Include filter options, and the ability to let the member choose if they want to appear in the directory or not
  • Ability to manage who has access to that page (can be either public or secured by user account login)

Each section can manage its own dedicated directory page.

QF13: Am I right that on the national ACC site, members will log in using their email address?

Using their member number would be a pain because they typically would not remember them.  This is also why I don't understand we would force them to use a member ID to login to our section websites. Not a consistent user interface.

That is correct - members will be able to login using their email addresses and password. Alternatively, if they are unsure of their email address, they will be able to use their member number + dob.

 

Q14: Do you know if there is a rate limit on the API? And is the API functional already?

There will be a rate limit per minute but we can’t confirm it yet. And no the API is not functional yet, it will need to be activated on the Interpodia side once we know the section expectations.

Q15: Is it possible then for the membership query API to accept an email address for input? 

It will require a few hours of custom development but yes it would be possible.

Q16: Could you give an example of multiple profiles a user would have? Would this be family members (children) for example?

More information in that guide (currently being updated): Profile data management overview

Q17: Does a separate membership purchase notification email get sent out by Interpodia for each membership purchase even if the purchases were all stemming from the same ORDER? Or, Would there be a single email sent to the USER ACCOUNT when a family membership is processed that would list the member numbers of all the PROFILES under that USER ACCOUNT for which there were new MEMBERSHIPS purchased?

The 2M-Interpodia system sends different types of notification emails to the member: 

  • Receipt email: one per order, to the purchaser email only (email of the PRIMARY PROFILE on the USER ACCOUNT)
  • Membership purchase confirmation email: one per membership purchased, to the member's email address (email on the member's profile)
    • If the order contains memberships for multiple people (eg: family), then each person will get the membership purchase confirmation email to their own email as listed on their individual profile
    • If the order contains multiple memberships for a single person (eg: ACC + sections), then the person will get one email per membership type
  • Membership issued confirmation email: (aka welcome email) that email is being sent once the membership has been switched to issued (fully paid for + all waivers signed) for each member and each membership type. 

Q18: What happens when an ORDER includes multiple MEMBERSHIPS (different ACC Sections) for a single PROFILE; does the membership purchase notification email go out to each Section included in the ORDER?

By default, we do not set up membership notification emails going out to section admins, but that's an option available on our system upon request (no setup fees). 

 

Related articles