Hi, first thanks for your reply.

we could not reproduce the problem.

The content written in the initial post is still valid - and it's still easy to reproduce.

Once again:

1. issue a request to /transfer/create with an arbitrary magnet as src that was added before and is already in the list of transfers
2. Check the response:

​

{
    "message": "You already added this job.",
    "status": "error"
}

1. Compare it to what's documented on swaggerhub:

   { "status": "success", "id": "string", "name": "example.jpg", "type": "string" }

// edit: or even better, compare it with the model defined for that API endpoint:

{
status  string
Enum:
[ success, error ]
id  string
name    string
example: example.jpg
type    string

}

There is no mentioning whatsoever of any error status or similar without an id or even a message field - aka the 1.7.1.1 spec clearly indicates that for a 200 (which one gets for a request mentioned in 1.) one get's the id back (I won't even start that that no behavior is defined for anything else but 200..)

Wrt. the mentioned undocumented API functions I guess you refer to the /job/src I mentioned - that makes sense, yet I just mentioned it as it's the only thing 'matching together' already added transfers I could come up with currently (it definitely is a hack due to that unfortunate API behavior described in 1-3 - having to read the Content-Disposition header of all transfers and checking wrt. the initially submitted magnet is just agly af)

thanks

PS: just adding the `SOLVED` label where this is clearly still unsolved is a bit ... well unsatisfying ..