I think, at least initially, this might be simplest to implement as a "something has changed" event that hits the necessary 3rd party endpoint and sends the tournament id/name, time, maybe an event id? If the tournament log were exposed as an api endpoint, then the connected app could query the log securely for any and all events since that event occurred and process them as needed. That could also be paginated to prevent lengthy API calls.
That allows the outgoing http POST request to be open because it contains nothing but a time and some ids. The subsequent incoming requests for more information would then be secured by Basic Auth. In theory, that should reduce the need for automatic polling of the API by 3rd party apps and allow you to scale the number of required instances based on real demand.
I think, at least initially, this might be simplest to implement as a "something has changed" event that hits the necessary 3rd party endpoint and sends the tournament id/name, time, maybe an event id? If the tournament log were exposed as an api endpoint, then the connected app could query the log securely for any and all events since that event occurred and process them as needed. That could also be paginated to prevent lengthy API calls.
That allows the outgoing http POST request to be open because it contains nothing but a time and some ids. The subsequent incoming requests for more information would then be secured by Basic Auth. In theory, that should reduce the need for automatic polling of the API by 3rd party apps and allow you to scale the number of required instances based on real demand.