This scenario is quite frequent among our customers. However, Tickera does not support recurring events functionality which, in this case, would be the perfect solution. Still, there are certain workarounds for this that might help you setting up scenarios like this.
Depending on the details and priorities of your scenario, there are two possible approaches for this: creating a separate event for each of the occurrences or creating a single event. We'll explain pros and cons of both.
This method considers creating a separate event, with separate sets of ticket types and separate seating chart (if you will be using this feature) for each of the occurrences of your event. This approach is the most failsafe as customers will be purchasing a ticket for the particular event so their ticket will be eligible for check-in at that event only. Also, this makes it possible to sell the tickets for each occurrence separately but you can also apply a workaround explained here to sell the tickets for multiple occurrences with (optionally) discounted price in a single go.
The main con of this approach is that if customer wants to attend multiple occurrences, they will end up having a separate ticket for each which might cause a confusion.
With this approach, you will be using different API key in the Check-in app for each occurrence.
When taking this approach, you will be creating a single "master" event. Now, if you want your customers to be able to purchase both the tickets for individual occurrences and for all the occurrences (eg. season tickets), you should then create a separate ticket type for each of the occurrences and name them accordingly so that customer undoubtedly knows which occurrence they are purchasing their ticket for. Also, each of these ticket types should have check-in availability set to match the start and end date/time of the occurrence they represent as this will prevent these tickets from being checked-in on any other occurrence but the one they represent.
Now, apart from the ticket types for individual occurrences, you can also create one ticket type that has either open ended or check-in availability that has broader date/time range than ticket types for the individual occurrences. These ticket types will be suitable for having a season pass or admittance on multiple occurrences.
The main pro of this approach is that you will be having only one event, thus you will be always using the same API key in the Check-in apps and customers will be purchasing only one ticket for either individual or multiple occurrences.
However, the pitfall of this approach is that you won't be able to use Seating Charts add-on as there is no possibility to automatically reserve seats in multiple seating charts (which you would need to have for individual occurrences) if customer purchases, for example, a season ticket.
Another con of this approach is that, if for example, you have a three day event, and want to allow customers to check-in once per day, you can only limit the number of available check-ins to three but then you must be careful not to check their ticket twice at the same day as there is nothing that would prevent this.