Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/fredy-rizo/gestor-backend/llms.txt

Use this file to discover all available pages before exploring further.

Player transfers in Gestor Deportivo follow a two-step approval process. The source team’s owner initiates the request, and the destination team’s owner must explicitly accept it before the player moves. This ensures that no player can be transferred without consent from both sides, and every transfer is logged in a permanent TransferPlayer record for audit purposes.

​
Transfer workflow

1

Source team owner initiates the transfer

The owner of the team where the player currently plays sends the transfer request, specifying the destination team.
curl -X POST https://api.example.com/api/team/transfer/<playerId>/-/<sourceTeamId>/player \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "destinationTeamId": "<destinationTeamId>"
  }'
Path parameterDescription
:playerIdID of the player being transferred
:sourceTeamIdID of the team the player is currently on
Body fieldDescription
destinationTeamIdID of the team that should receive the player
On success, the API returns the new TransferPlayer document. Note the _id — you may need it for auditing, though the acceptance step uses the destination team ID directly.
2

Deduplication check

The API automatically checks whether a pending transfer already exists for this player between the same two teams. If one does, the request returns an HTTP 203 with an informational message rather than creating a duplicate record. No further action is needed on your part — the original transfer request remains active.
{
  "status": 203,
  "message": "A pending transfer already exists for this player."
}
3

TransferPlayer record is created

When the transfer is accepted, a TransferPlayer document is persisted linking three sub-documents:
  • player — a snapshot of the player’s profile at the time of transfer
  • currentTeam — the source team the player is leaving
  • targetTeam — the destination team the player is joining
The record’s acceptsTransfer field is initially false and flips to true once the destination team owner accepts.
4

Destination team owner accepts the transfer

The owner of the receiving team approves the incoming transfer. This is the action that physically moves the player.
curl -X POST https://api.example.com/api/team/accepts/<destinationTeamId>/transfer \
  -H "Authorization: Bearer <token>"
Accepting a transfer is irreversible via the API. Once accepted, the player is immediately removed from the source team’s roster and added to the destination team’s roster. If the move was made in error, you must initiate a new transfer in the opposite direction to move the player back.
5

Roster and player record are updated

On a successful acceptance, the API performs three operations atomically:
  1. Removes the player from the source team’s roster array
  2. Adds the player to the destination team’s roster array
  3. Updates the player’s own teamId array to reflect the new club
The TransferPlayer record’s acceptsTransfer field is also set to true, preserving a complete history of the move.

​
Curl examples

​
Initiate a transfer

curl -X POST https://api.example.com/api/team/transfer/64f3c1a2e4b0c72d9f1e8a00/-/64f3c1a2e4b0c72d9f1e8b11/player \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "destinationTeamId": "64f3c1a2e4b0c72d9f1e8c22"
  }'

​
Accept a transfer

curl -X POST https://api.example.com/api/team/accepts/64f3c1a2e4b0c72d9f1e8c22/transfer \
  -H "Authorization: Bearer <token>"

​
Error reference

ScenarioHTTP statusDescription
Duplicate pending transfer exists203A transfer for this player between the same teams is already pending. The existing request remains active.
Player not found404No player exists with the given :playerId. Verify the ID and try again.
Source or destination team not found404One of the team IDs is invalid. Check both :sourceTeamId and destinationTeamId.
Caller is not the destination team owner403Only the owner of the destination team can call the accept endpoint. Ensure you are authenticating with the correct account.
Every transfer — whether pending or accepted — is stored as a TransferPlayer record. This gives you a complete audit trail of all player movements across your organisation. You can use these records to reconstruct a player’s club history, verify past transfers, or resolve disputes about roster eligibility.

Build docs developers (and LLMs) love

Get started for freeTalk to us