Guidance on Check-ins API Calls

[joshb227]

Related Product
Which product is this question related to?
Check-ins

Describe the question
I am working on a dashboard that deals with first-time check-ins to a particular event during a given month. The main component is a table where each row represents a person, and there are columns for phone number, grade, and school, as well as a column for each event_period in the given month, as well as the following month. A check mark is placed in those columns if the person checked in to that particular event_period. The idea is we want to see whether first-time check-ins for a given month visit us at least two more times before the end of the following month.

This is all working well enough, but I'm wondering if there are any tips to speed up the data retrieval. Currently I call /check-ins/v2/events/xyz/event_periods and query by starts_at and ends_at to get the event_periods for the given timeframe. Then I page through /check-ins/v2/events/xyz/event_periods/abc/check_ins for each event_period to get the list of people who checked in to each period. I ALSO make another request to the periods in the specified month, this time using the first_time filter.

At that point, I have all the attendance data that I need, but I have a feeling it could be improved to lessen the time the user spends looking at a spinner. For example, I wonder if there is a way to distinguish between first-time check-ins using only the response from our first set of calls, without having to call the same endpoints again with the filter parameter. Additionally, because we only display first-time check-ins during the month specified by the user, I disregard all check-ins from the following month that didn't check in during the specified month. I wonder if there's some clever way to exclude them from the calls in the first place to significantly reduce the result set.

After all that, I still have yet to fill in the personal info columns for each row. I believe I'll have to make calls to the People API for those columns. Rather than making individual calls for each person, I see that it is possible to query /people/v2/people with a list of IDs. However, I imagine I could run into very long URLs if I try to just throw all of my attendee's IDs into a call. Can you offer any guidance about the fastest way to retrieve that info for each of our attendees?

Any efficiencies at all are welcome, and thank you in advance for your input!

I have..

• Reviewed the documentation found at https://developer.planning.center/docs
• Searched for previous issues answering this question
• Removed all private information from this issue (credentials, tokens, emails, phone numbers, etc.)
• Reviewed my issue for completeness

[chris-durheim]

Hi Josh - I'm a developer on the Check-Ins team - I'm happy to provide assistance!

Follow-up Question

Could you share what kind of performance times you're seeing with the process today? That'll help me get an idea of what kinds of improvements are realistic.

Another Option?

Depending on your use case, the questions of "Which first-time attendees for month X for event Y returned at least 2 times more before the end of the following month" and "Which did not?" could both be answered by People Lists as well.

For example, I believe this would show, for a given event in February, the list of first-time attendees who come back at least twice:

And this would show, for that same event, the list of first-time attendees who don't come back at least twice:

[chris-durheim]

@joshb227 - I think your overall approach seems sound.

If the People List approach doesn't work for your use case, I have couple ideas to improve performance below. I hope these help optimize your approach!

Request Caching

If your users are going visiting the same view multiple times, I'd consider caching response data locally to prevent re-fetching.

Use include

After all that, I still have yet to fill in the personal info columns for each row. I believe I'll have to make calls to the People API for those columns.

If you use include=person as a param when querying the check-ins, you'll get person data included in the response (in the included section of the payload).

This should keep you from having to query the people API

Order of Operations

Currently I call /check-ins/v2/events/xyz/event_periods and query by starts_at and ends_at to get the event_periods for the given timeframe. Then I page through /check-ins/v2/events/xyz/event_periods/abc/check_ins for each event_period to get the list of people who checked in to each period. I ALSO make another request to the periods in the specified month, this time using the first_time filter.

With your current approach, you're over-fetching a bit by getting all check-ins for those event periods. That includes check-ins for people who didn't check-in for the first time.

I'd consider changing the order and scoping of these slightly:

1. Query the event periods (as you are now)
2. Query the first-time check-ins for those event periods - grabbing their account_center_ids
3. Query the event periods for just the people with those account center ids (using a where param)

This should give you the check-ins only for the people you're focused on - those who checked in for the first time during the month in question.

If you're concerned about the length of the URI for this (as per your comment on "I imagine I could run into very long URLs if I try to just throw all of my attendee's IDs into a call"), you could run the queries in step 3 in batches of account_center_ids to break up the work but still get the benefit of not having to do each one individually.

[joshb227]

Chris, thanks for your comments and suggestions! I think I will chunk the URL into smaller requests, what is a safe limit for URL lengths hitting the API? Thanks again!