There's a subtle difference between Yes, you can use POST for updates and yes, it's ok using POST for updates.

Indeed (technically) you can, but it's not ok; unless you are dealing with some rare constraint. Or you are intendedly implementing RPC-like APIs (I think this is not your case).

The reason why it's not ok can be understood reading the other 2 answers and the comments below the question. It's contrary to the HTTP semantics and it's confusing.

Confusing for who? For whoever is familiar with the HTTP verbs and is meant to work with your API. Especially confusing for HTTP Clients that were built to work in a very specific way. Most of the time, it's irrelevant for these clients but not for those developers who have to use the client and, all too sudden, note that it doesn't behave as expected.

Often, we have what I call "happy ideas". Happy ideas make a lot of sense to us. We understand them, they are obvious, they work. The thing is if we reach them upon false premises or rationales, lack of knowledge or absolute ignorance.

If you are familiar with the HTTP semantics and you want your API not to cause a funny WTF time, then you won't use POST for updates. Because it's weird and it makes hard someone's else job.

Could this way bring some issues that I don't see at the moment?

Hard to say. It will depend on how you screw with the semantics.

There's a subtle difference between yes, you can use POST for updates and yes, it's ok using POST for updates.

Technically, you can but it's not ok; unless you deal with some rare constraints or you are implementing an RPC web interface.

Why is not ok? The reason is in the other two answers and comments. It's weird. It's confusing.

Confusing? For whom? On one side, for whoever is familiar with the HTTP verbs and have to work with your API. On the other hand, Http clients are implemented to work in a very specific way. Ok, your idea will work on most of the Http clients out there, but you will be making someone else job harder when all too sudden the client stops working as expected.

Allow me to share a reflection. Often, we have what I call "happy ideas". Happy ideas make a lot of sense to us. We are something obvious, brilliant, they work, they are ok. 

The thing is if we reach them upon false premises or rationales, lack of knowledge or absolute ignorance.

If you are familiar with the HTTP semantics and you don't want your API to cause some funny WTF time, then you won't use POST for updates. Because it's weird and it makes hard someone's else job. It bears an unnecessary cognitive burden.

Could this way bring some issues that I don't see at the moment?

Hard to say. It will depend on how the happy idea is complicating things. If you have to make this question to strangers on the internet then it's not a good idea. Learn HTTP first, get familiar with it. Then twist it safely as you deem it necessary.

There's a subtle difference between Yes, you can use POST for updates and yes, it's ok using POST for updates.

Indeed (technically) you can, but it's not ok; unless you are dealing with some rare constraint. Or you are intendedly implementing RPC-like APIs (I think this is not your case).

The reason why it's not ok can be understood reading the other 2 answers and the comments below the question. It's contrary to the HTTP semantics and it's confusing.

Confusing for who? For whoever is familiar with the HTTP verbs and is meant to work with your API. Especially confusing for HTTP Clients that were built to work in a very specific way. Most of the time, it's irrelevant for these clients but not for those developers who have to use the client and, all too sudden, note that it doesn't behave as expected.

Often, we have what I call "happy ideas". Happy ideas make a lot of sense to us. We understand them, they are obvious, they work. The thing is if we reach them upon false premises or rationales, lack of knowledge or absolute ignorance.

If you are familiar with the HTTP semantics and you want your API not to cause a funny WTF time, then you won't use POST for updates. Because it's weird and it makes hard someone's else job.

Could this way bring some issue that I don't see at the moment?

Hard to say. It will depend on how you screw with the semantics.

There's a subtle difference between Yes, you can use POST for updates and yes, it's ok using POST for updates.

Indeed (technically) you can, but it's not ok; unless you are dealing with some rare constraint. Or you are intendedly implementing RPC-like APIs (I think this is not your case).

The reason why it's not ok can be understood reading the other 2 answers and the comments below the question. It's contrary to the HTTP semantics and it's confusing.

Confusing for who? For whoever is familiar with the HTTP verbs and is meant to work with your API. Especially confusing for HTTP Clients that were built to work in a very specific way. Most of the time, it's irrelevant for these clients but not for those developers who have to use the client and, all too sudden, note that it doesn't behave as expected.

Often, we have what I call "happy ideas". Happy ideas make a lot of sense to us. We understand them, they are obvious, they work. The thing is if we reach them upon false premises or rationales, lack of knowledge or absolute ignorance.

If you are familiar with the HTTP semantics and you want your API not to cause a funny WTF time, then you won't use POST for updates. Because it's weird and it makes hard someone's else job.

Could this way bring some issues that I don't see at the moment?

Hard to say. It will depend on how you screw with the semantics.