Do you have any recommendations for fleshing it out?

I guess that depends on what else you want to add to it, but I think Mojolicious::Lite is fine for scripts that have up to a couple of pages of code. If it starts growing to more than that, you probably want to split it into a multi-file application, see Mojolicious::Guides::Growing for that. For most things, e.g. authentication, different response types, etc., a read of Mojolicious::Guides::Tutorial is strongly recommended.

I can include a sub to parse the $dom after the app->start, yeah?

It's a regular Perl script, so you can include the sub almost anywhere in the script. app->start is just the entry point for the main loop. Of course, code modularity best practices should still be followed, so if the code gets too long you might want to split it out into a separate module and so on.

It would take the contents and push it up into another system's API.

See Mojo::UserAgent, or in case it's a database, see Mojo::Pg and several similar modules for other databases. The asynchronous nature of these kinds of APIs are very well represented by Mojolicious, so for example, if you want to delay the sending of the response to your clients until your other API has given you a response, you can use e.g. render_later and then for example send your response from the Mojo::UserAgent callback or promise (example; I've also posted a bunch of Mojo examples, several are linked from my scratchpad). (Update: I just posted an example of the aforementioned promise handling in my other reply.)

What's best practice for running a Mojo server as a service so I can avoid manually starting it?

I'm not sure about other best practices in that case, but I run my Mojo apps either as systemd services based on the information in Mojolicious::Guides::Cookbook, or I run hypnotoad in a Docker container (in that case with hypnotoad -f /path/to/script.pl).