[SOLVED] What are the correct Travis API calls (or library methods) to first start and watch a build and later retrieve its status and build log?

What are the correct Travis API calls (or library methods) to first start and watch a build and later retrieve its status and build log?

In one of my applications, I want to trigger a Travis CI build, "watch" the build as it is scheduled, run and finishes, then retrieve the final build state and the build log to output it in my app.

I started by triggering a build with the API, which gives me a Request and its request.id. This works perfectly.

Then I can retrieve this Request, which includes the Request.state and an embedded Build and its Build.id along with the Build.state, using the /repo/.../request/#id endpoint.
I could then start polling /build/#id endpoint to monitor the state every second.
As soon as the build is finished, I can use the Job that is part of the Build (when requested from /build/#id) to download the log from /job/#id/log and display it in my application.

This all sounds pretty inefficient.

Is there a better way to achieve this?
Is there a "quicker way" (= less requests) from creating the request to log?
Can I avoid the manual polling somehow?

Solution

I will use this answer to document my own research that might help resolve this:

Travis CI API supports eager loading via ?include. Using this, I can already get the Job.id in the Request response via the extended Build objects: ?include=request.builds - I don't have to do another request to build endpoint for the Job.id. But as I need to poll for status changes, this doesn't really help much.
As @Maël Pedretti suggested in the comments, Travis supports webhook notifications. The submitted object contains an id which is the Build.id, so this could replace the polling part I described above. As my app doesn't just run on one server that can be configured as the webhook url though, I need a stateful server component that my app could poll or listen to. So just a horse trade :/