The unique identifier of the connection you want to allocate funds to.

This connection:

• Must be a valid, established connection between your enterprise and a partner.
• Determines where the allocated funds will be available for use.
• Should be pre-established before attempting to allocate funds.

The unique identifier of your enterprise.

This identifier:

• Represents your organization within the BitGo system.
• Is used to validate you have permission to perform this action.
• Must match the enterprise associated with your API credentials.

A unique external identifier for the allocation.

This identifier:

• Must be unique for each distinct allocation request.
• Is used for idempotence to prevent duplicate allocations.
• Allows clients to correlate allocations with their own systems.
• Should be stored by the client for tracking and reconciliation.

Unique nonce to prevent replay attacks.

This value:

• Must be unique for each request requiring a nonce.
• Should be a cryptographically strong random value.
• Is used as part of the request signing process.
• Helps ensure the signature can only be used once.

Optional notes to attach to the allocation.

These notes:

• Can provide additional context about the purpose of the allocation.
• Are stored with the allocation record.
• May be useful for auditing, record-keeping, or operational purposes.
• Are visible to both client and partner.

Payload formed by stringifying the object containing all other request properties.

This includes:

• amount: The amount to allocate.
• clientExternalId: Your unique identifier for this allocation.
• nonce: A unique value to prevent replay attacks.
• notes: Optional notes about the allocation.
• connectionId: The connection to allocate funds to.
• enterpriseId: Your enterprise ID.

The payload must be signed using your BitGo account's private key to create the signature parameter.

Digital signature of the payload parameter.

This signature:

• Must be created using your BitGo account's private key.
• Verifies that the request is authentic and hasn't been tampered with.
• Provides non-repudiation for the allocation request.