POST /api/v1/transfers/internal ● Idempotency-Key: UUID (обязательный) ● Authorization: Bearer <token> { "source_account_id": "83740e53-689c-[phone]f9e61f22401", "destination_account_id": "[phone]f5c-[phone]a", "amount": 1500.50, "currency": "USD", "description": "Payment for rent", "save_as_template": true } { "status": "success", "transaction_id": "77e1c83b-7bb0-437b-9250-8c9339e0538b", "data": { "amount": 1500.00, "currency": "USD", "executed_at": "[phone]T23:15:00Z", "template_saved": true } } [The sequence diagram and database schema are provided for context on the transfer service, business logic, event publishing, and database structure.]

This request describes an internal transfer between accounts via API with a mandatory Idempotency-Key header to ensure operation idempotency and authorization via token.

Key points:

• Idempotency-Key — a unique UUID that guarantees that a repeated request with the same key will not result in a duplicate deduction of funds.
• The request body contains account identifiers, amount, currency, description, and a save template flag.
• The response returns status, transaction ID, and execution data, including whether the template was saved.

Example of using idempotency:

If the client accidentally sends the request twice (for example, due to a timeout), the server recognizes the repeat by Idempotency-Key and will not create a duplicate transaction.

Business logic checks:

• Balance check on the outgoing account.
• Validation of currency and amount.
• Updating balances in the database.
• Publishing events for other services.

This ensures reliability and consistency when performing internal transfers.