If the 3rd party can send HTTP headers too you could send to them the current user's session id. If that user is API enabled (checkbox in profile/permission set) - you could write an Apex REST service that accepts POSTs. They'd call it with Authorization: Bearer <session id here> and it could work very nice. This trailhead might be a good start for you. (or can you contact their developers and maybe agree to make a dedicated user in SF for them so they'd log in under their own credentials and send it back?)
If they cannot send any special headers (it'd have to be unauthenticated connection to SF) - maybe you could make a Visualforce page, expose it as Site and then page's controller can do whatever you need. Maybe you already have something public facing (community?), maybe it'd be totally new... Check https://developer.salesforce.com/docs/atlas.en-us.206.0.salesforce_platform_portal_implementation_guide.meta/salesforce_platform_portal_implementation_guide/sites_overview.htm
If none of these work for you - does the url have to ping back to Salesforce. Maybe you have control over another server that can accept unauthenticated requests like that and have that one then call SF. Bit like a proxy. You could even set something up fairly easily on Heroku.
Last but not least. This would be extremely stupid but if all else fails - in a sandbox enable Web-to-Case or Web-to-Lead and experiment with these. At the end of the day they give you an url you can POST to and pass a form with data. I think it'd have to be Content-Type: application/x-www-form-urlencoded and if you mentioned JSON they're likely to send it as application/json so might not work. If it works - you could maybe save the payload in Description field of Cases (special record type maybe?) and do something with it. I'm seriously not a fan of this.