I may be incorrect on this part, but I believe the authentication/access token flow does not use up any of your API calls. It is only calls to API endpoints which count towards your limit.

As far as optimizing calls, I’ve posted some comments before about what I do. Try this one

A big part of how many API calls you use also comes down to what data you need and how often you need it. If you’re fetching activity streams then you need at least 2 API calls per activity. Add another if you’re updating the activity.

The other big one is to use Webhooks if you haven’t already enabled them. That will move your app to a push model instead of a pull model, so you don’t have to waste API calls polling for activities and can instead react to the webhook.

Also, I would add more here. Some users tend to upload several smaller activities, for example, 1 activity per running interval. You have to handle such users in a way that doesn't starve sync of other users, especially if you tend to retrieve activity for each webhook event (so one api call per webhook event). For example, if you have 100 users, you can decide to allow 20 syncs per user. As application grows, you have to be able to scale. When user base grows to 200 users, daily allowance will be 10 syncs, for 1000 users, only 2 syncs, etc. So, the main idea is to avoid starving and make as even distribution of calls per user as possible. This is only one way how you can implement dynamic daily allowance. You can also make something more complex, by calculating how many users are really active daily on average, and decide to scale on that number, or make more complex formula like daily_api_limit / avg_number_of_active_users * scaling_factor. Also, if you reach the last allowed daily sync for user, as a fallback solution you can decide to delay syncing until the end of the day, and then retrieve all activities in the last 24 hours with one api call only (this actually depends on that whether you're satisfied with the SummaryActivity, or you need DetailedActivity).