API: POST /repositories returns a 404 Not Found error.

[Tealk]

I am unable to create repositories via the API, as I consistently encounter a 404 error; however, retrieving the repositories functions correctly.

curl -i -X 'POST' \
  'http://raw.githubusercontent.com/api/project/1/repositories' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer xxx' \
  -d '{
  "name": "TestRepo",
  "project_id": 1,
  "git_url": "https://git.rollenspiel.monster/ansible-playbooks/test.git",
  "git_branch": "main",
  "ssh_key_id": 0
}'
HTTP/2 404 
server: nginx
date: Sun, 01 Mar 2026 20:38:07 GMT
content-type: application/json
content-length: 0

[Lujain-ALghamdi]

The endpoint itself looks correct — Semaphore does support:

POST /api/project/{project_id}/repositories

and the request body you're sending is also close to what the API expects.

Since GET /api/project/1/repositories works but the POST to the same path returns a 404, I'd first rule out the reverse proxy rather than the Semaphore API itself.

A couple of things I'd try:

1. Send the same request directly to Semaphore, bypassing nginx if possible.

For example:

curl -i -X POST \
  'http://localhost:3000/api/project/1/repositories' \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_TOKEN' \
  -d '{
    "name": "TestRepo",
    "project_id": 1,
    "git_url": "https://git.rollenspiel.monster/ansible-playbooks/test.git",
    "git_branch": "main",
    "ssh_key_id": 0
  }'

If that works directly against Semaphore but fails through nginx, then the proxy configuration is the likely place to look.

I'd also check whether your nginx config has any method-specific rules or location blocks that treat POST requests differently from GET requests.

Another thing worth checking is the key ID. Semaphore's API expects ssh_key_id to refer to a valid key from the project's Key Store. If this is a repository that doesn't need authentication, I'd verify what key ID Semaphore created for the "None" key instead of assuming 0.

You can check the available keys with:

curl \
  -H 'Authorization: Bearer YOUR_TOKEN' \
  'https://your-semaphore-host/api/project/1/keys'

Then use the appropriate ID in ssh_key_id.

So I'd narrow it down in this order:

• test the POST directly against Semaphore without nginx
• verify that project 1 exists and the token has permission to manage that project
• check the actual Key Store ID instead of assuming ssh_key_id: 0
• compare nginx handling of GET vs POST requests

Because the repository creation route definitely exists in Semaphore, a plain 404 here makes me suspect that the request may not be reaching the expected Semaphore handler.

Hope this helps! If you can share the nginx location block for Semaphore and the response from the direct localhost:3000 test, it should be much easier to narrow down.

[Tealk]

Thanks for the detailed analysis — that was a good starting point. I investigated further and found the actual root cause: it's not the reverse proxy or the route at all.
I reproduced it live against my instance (Semaphore 2.19.12, behind nginx):

1. Bypassing nginx wasn't necessary — even directly through the reverse proxy, GET /api/project/1/repositories returned 200 and the POST works.
2. The 404 only happens when ssh_key_id does not exist in the project's Key Store.
   Specifically:

# ssh_key_id: 0  ->  404 (empty body)
curl -X POST 'https://host/api/project/1/repositories' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer TOKEN' \
  -d '{"name":"Test","project_id":1,"git_url":"https://...","git_branch":"main","ssh_key_id":0}'

# valid key id (from GET /api/project/1/keys)  ->  201, repo created
curl -X POST 'https://host/api/project/1/repositories' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer TOKEN' \
  -d '{"name":"Test","project_id":1,"git_url":"https://...","git_branch":"main","ssh_key_id":8}'

So your point #3 ("the Key Store ID instead of assuming 0") was exactly on target. The problem is that Semaphore returns a bare 404 without body for an invalid ssh_key_id, which is indistinguishable from a missing route. For comparison, a mismatched project_id correctly returns 400 {"error":"Project ID in body and URL must be the same"} — so the validation layer does work, only the key lookup misbehaves.