There are a number of factors here to consider. The first thing I think you might want to consider is that Date-times and calendar dates are not really the same thing. It's tempting to think that calendar dates can always be represented with date-time structures but this isn't really the case and doing so can often create complications in logic.
A common issue is that a date-time implies some sort of time zone. If you are building a system that is used across time-zones, a date-time can be problematic if what you really mean is a calendar date. For example, let's say you use Zulu time (UTC) across everything. It could be Dec 31 UTC but Jan 1 in Australia. Which is the right date for your system? If it's the local calendar date, then you've created a problem for the users of this API to solve.
Another common issue that can arise is that the system may have rules such as "transactions after 5PM are logged on the next business day". Assuming you use exclusive date-time as the end of the period, what does it mean if I pass in midnight on Jan 1? Is an event that occurred at 6PM Dec 31, included? If not, the use of date-times becomes Now the code that calls this needs to encode these business rules into the calls and that gets spread throughout the code base. Then later, let's say the cutoff changes to 6PM. See the issue?
That you are asking this suggests to me that your requirements are based on calendar dates and not date-times. If that's correct, you should build an API that accommodates that directly. Note, however, that this doesn't proscribe providing another method that takes date times in addition to the simple month-based version. As you say, this is more generic and can be used in the solution for the month-based implementation.