Is the code prone to SQL injection or to any other kind of threat
SQL injection should not be a problem, as long as you pass any user input to queries through placeholders, which you do.

I have a few other remarks though

Single Responsibility Principle

In the first code snippet you do too much things. You decode request json, you talk to db. you handle the logic, you maintain response structure. It would be wise to separate those things into their own scopes (functions/classes). Of course if this is all you ever intend to have there may be no point. But in general, in future you will want to reuse the individual pieces.

Global Scope vs. Classes and Dependency Injection

You may want to avoid definind global variables. It's generaly considered bad practise for several reason which I'm not gonna repeat here as there is plenty of information sources for this already.

You are probably not very familiar with the concept of OOP, but wrapping those function into class scopes and working with objects may be something for you to learn.

If you want to stick with procedural style, maybe at least get rid of the globals by passing the db connection always as function parameter.

if (clientExists($connection, $clientName)) {...}


It is annoying but it is still better then globals, in some ways anyway.
That where the objects could help if you get used to it.

$users-&gt;exists($clientName)


Data Validation

You check that $input['clientName'] is set. Is it enough? What if it is empty? What if it is array or number? Is it ok? What if $input is not an array in the first place? All that should be handled.

Validation is btw, yet another responsibility that might be separated to its own function.

Useless Statements

In the clientExists() function I think you fetch the row for now reason. It should be able to tell count without fetching it.
You can also simplify the select from SELECT clientName to SELECT 1 which is, IMO, cleaner as you could actualy select any of the table's column for it to work and if that column ever changes name this would have to change too.

Public API

At this point your api is public in whichever network in which it is deployed. As this network is probably going to be the internet (I suppose), anyone will be able to call it. Is it ok if any anonymous client can succesfully call this endpoint and so create db entries? You may want to have some way of authentication, but this depends on your use-case.