To answer your first question: No, I don't believe you have much to worry about. In particular, they are authenticating themselves, and I think you have some confusion in terminology going on here. The fact that the auth token is in the request body doesn't change anything about authentication. Many API calls work this way (although passing the auth token in the header may be more common). If you contacted them and tried to address the lack of authentication (like you are here) I'm sure they would have dismissed your concerns, because they are in fact authenticating themselves.
Regarding your concerns over DDOS, the difference between getting an auth token out of a header (which is probably the only other place it can live) and parsing it out of a JSON body is very minimal from the perspective of CPU usage. I don't expect it to make any practical difference in helping an attacker succeed in a DDOS attack. In all likelihood you have much more CPU intensive pages than this anyway, so if someone were to perform a targeted attack against your system and take the time to try to find the weakest endpoint, there are probably many much more tempting pages to be found.
However, even that isn't a real concern. Most DDOS attacks these days work by simply throwing as many requests at the target as possible to saturate their network bandwidth. As a result, the actual endpoint doesn't even matter, and the requests the attackers send are very rarely valid requests anyway. I doubt many attackers would bother doing more than looking up the IP address of your server(s), and there are probably very few circumstances in which they would first spend time looking around your website trying to find the most vulnerable page.
If you are concerned about DDOS get a DDOS mitigation partner like cloud flare. As Josef mentions, you can also try IP address limits on the page. However, there are much more effective ways to spend your time to protect your site against DDOS then trying to change the API structure of a third party service when your application has plenty more endpoints for an attacker to hit anyway.
In the security world no answers are especially helpful without good threat modeling. As a result, it's worth breaking down the "threat model" you are concerned about. Having a request that passes the auth token in the body is important if:
- Someone is targeting your system for DDOS attack
- They don't have enough bandwidth at their disposal to simply overrun your network resources (DDOS of network resources via amplifications attacks alone accounts for ~half of all DDOS attacks)
- They therefore decide to target particular endpoints in your system that are resource-intensive
- They happen to stumble upon this unpublished endpoint and are able to figure out how the API call works
- They don't find another endpoint in your system that is more resource intensive
If all of those conditions are met, then indeed, someone might use this endpoint to DDOS your system, and the difference between authentication in the header and in the body may in fact matter. However, in case it isn't clear, these conditions are never going to be met. If someone wants to DDOS your systems they will probably just go off and rent a DDOS that will flood your systems with meaningless network traffic. It is both easier and more effective then trying to identify an actual weak point in your system. This is the primary reason why this doesn't matter from the perspective of a DDOS: the DDOS attack you are worried about is never going to happen because there are easier and faster ways to DDOS a website than this. The only way to protect against realistic kinds of DDOS attacks is with a DDOS mitigation provider.
This is why threat modeling and understanding real world threats is so important. You can spend weeks working with a third party provider to change their API in a way that minimizes CPU time on your end, only to then have your systems knocked out by a DDOS that blindly sends invalid requests into your network and overwhelms your network capacity. If you spend your time protecting against the wrong kinds of threats, you can end up wasting a lot of time and (more importantly) implementing the wrong kinds of safe guards.