# Create Wire

Initiates a Wire Transfer. Wires can only be sent to accounts created and verified via [Create Counterparty](/products/partner-api/reference/counterparties-v2/create_counterparty_api_v2_customers__customer_id__counterparties__post).
Initiating outgoing wire transfers isn’t available by default and must be enabled — please contact your Jiko point of contact to learn more.
**Note:** `description` is sent to the beneficiary's bank with the wire, so it may only contain printable ASCII characters (letters, digits, space and standard punctuation), the character set the Fedwire Funds Service accepts. Any other character, such as an accented letter, a line break or a tab, is rejected with a `422` `InputValidationError`.
When implementing our Wire Transfer entry screens in your application's UI, you must include the following instructions for your end-users: *“By using this service, you hereby acknowledge that sending wires to third parties presents an increased risk of fraud, and that as per the terms of your Commercial Bank Account Agreement (the "Agreement"), you agree that our security measures are commercially reasonable methods of providing security against unauthorized Funds Transfers, and that you shall be bound by any request for a Funds Transfer received by the Bank, whether or not authorized, issued in your name and accepted by the Bank in compliance with the security measures.”*
### In Sandbox
In sandbox, Jiko reviews and processes an outgoing wire on its own shortly after you create it, so you don't have to wait for anyone at Jiko. The wire moves from `PENDING` to `SUCCESS` and you receive `transfers.wire.out.success`. The amount is debited from the account as in production, but nothing is sent to the beneficiary's bank.
A wire to a counterparty that isn't verified stays `PENDING`, as it would in production until Jiko reviews it.

Endpoint: POST /api/v1/jiko-accounts/{account_id}/wires/
Version: Version: 37bc941f
Security: HTTPBearer

## Description:

  - `In Sandbox` ()
    In sandbox, Jiko reviews and processes an outgoing wire on its own shortly after you create it, so you don't have to wait for anyone at Jiko. The wire moves from PENDING to SUCCESS and you receive transfers.wire.out.success. The amount is debited from the account as in production, but nothing is sent to the beneficiary's bank. A wire to a counterparty that isn't verified stays PENDING, as it would in production until Jiko reviews it.

## Security:

  - `HTTPBearer` (unknown)
    http bearer

## Path parameters:

  - `account_id` (string, required)

## Header parameters:

  - `x-jiko-idempotency` (string, required)
    A new UUID that you generate for each request, reads included. It is part of the request signature and prevents replay of a request. A value that was already sent in the last hour is rejected with `409 jiko.errors.DuplicateRequestError`, even if the first request failed. When you retry a request, generate a new value and sign the request again.

  - `x-jiko-signature` (string, required)
    Base64-encoded HMAC-SHA256 hash of `x-jiko-idempotency + request pathname + body`, keyed with your shared secret. See [Authentication](/products/partner-api/guides/building/auth) for the full algorithm and a code sample.

## Request fields (application/json):

  - `counterparty_id` (string, required)

  - `amount_usdc` (integer, required)
    The amount, in USD cents.

  - `created_by` (string, required)
    A string identifying the wire transfer originator.

  - `description` (any)
    A description of the transfer, visible on statements.

  - `wire_id` (any)
    The ID for this wire transfer, auto-generated if not provided.

## Response 201:

  - `201` (unknown)
    Successful Response

## Response 201 headers:

  - `Location` (string)
    The URL of the created wire.

## Response 401:

  - `401` (unknown)
    The access token is missing, invalid or expired.

## Response 401 fields (application/json):

  - `type` (string, required)

  - `instance` (string, required)

  - `detail` (string, required)

  - `trace_id` (any)

  - `fields` (any)
    Present only on input validation errors. Each entry identifies one invalid field: `loc` is its location, `msg` is the problem, and `type` is the validation rule that failed.

## Response 403:

  - `403` (unknown)
    `x-jiko-signature` does not match the request, or the access token does not permit this action.

## Response 403 fields (application/json):

  - `type` (string, required)

  - `instance` (string, required)

  - `detail` (string, required)

  - `trace_id` (any)

  - `fields` (any)
    Present only on input validation errors. Each entry identifies one invalid field: `loc` is its location, `msg` is the problem, and `type` is the validation rule that failed.

## Response 404:

  - `404` (unknown)
    A resource identified in the path does not exist.

## Response 404 fields (application/json):

  - `type` (string, required)

  - `instance` (string, required)

  - `detail` (string, required)

  - `trace_id` (any)

  - `fields` (any)
    Present only on input validation errors. Each entry identifies one invalid field: `loc` is its location, `msg` is the problem, and `type` is the validation rule that failed.

## Response 422:

  - `422` (unknown)
    Validation Error

## Response 422 fields (application/json):

  - `detail` (array)

  - `detail.loc` (array, required)

  - `detail.msg` (string, required)

  - `detail.type` (string, required)

  - `detail.input` (any)

  - `detail.ctx` (object)