Txn Bundle

Use Txn Bundle when you already have a signed transaction and want to submit it through Carbium's documented bundle path.

GET https://api.carbium.io/api/v1/swap/bundle

This page is intentionally narrow. It does not build, sign, or simulate a swap transaction. It accepts a base64-encoded signed transaction and returns bundle/submission identifiers when the request succeeds.

Part of the Carbium Solana infrastructure stack.

Where the bundle step belongs

A bundle endpoint sits late in the swap flow, after route selection and signing.

flowchart TD
  A[Quote or build transaction] --> B[Review route and slippage]
  B --> C[Deserialize transaction]
  C --> D[Sign with the required wallet or signer]
  D --> E[Submit signedTransaction to bundle endpoint]
  E --> F[Track bundleId and txId]

Use this page when the transaction is already signed. If you still need to build the transaction, start with Q1 or Swap. If you need the full sign -> submit -> confirm sequence, use Executing Swaps.

📘
Bundles are an execution tool, not a replacement for quote validation, slippage checks, fresh blockhashes, or signer hygiene. Submit only transactions your app has already validated and signed intentionally.

Request shape

Method: GET

URL:

https://api.carbium.io/api/v1/swap/bundle

Headers:

X-API-KEY: YOUR_API_KEY
accept: application/json

Parameter	Required	Meaning
`signedTransaction`	Yes	Base64-encoded signed transaction payload

Because base64 strings can contain characters that need URL encoding, prefer --get --data-urlencode in shell examples instead of pasting a long transaction directly into the URL.

Minimal request

curl --request GET 'https://api.carbium.io/api/v1/swap/bundle' \
  --get \
  --data-urlencode "signedTransaction=$SIGNED_TRANSACTION_BASE64" \
  --header "X-API-KEY: $CARBIUM_API_KEY" \
  --header "accept: application/json"

Set SIGNED_TRANSACTION_BASE64 only after your app has serialized a fully signed transaction.

export SIGNED_TRANSACTION_BASE64="AQAAAA..."
export CARBIUM_API_KEY="YOUR_API_KEY"

Do not send an unsigned transaction here and expect Carbium to sign it for you. The signing boundary remains inside your wallet, backend signer, custody provider, or bot executor.

Response fields

A successful response includes identifiers you can store for follow-up logging and support.

{
  "success": true,
  "data": {
    "bundleId": "f4227ba3c31ce9d689594e7bbc77d6516760732fa1011b9708564f49727f5622",
    "txId": "4WZqbtbNp7daeYQJQG9ydkiENgFrKmHmeQXzRwGTZg4GEEijuBhpXqEUMPfW5xSSSQixajvTn8JUNTM2BiEYmrTL"
  }
}

Field	How to use it
`success`	Confirms the API accepted the request shape and returned a submission result
`data.bundleId`	Bundle identifier for logging, support, and execution tracking
`data.txId`	Transaction signature/hash associated with the submitted transaction

A response from this endpoint is not the same as a completed product workflow. Your app should still track transaction status and surface failure states clearly to users or operators.

What to validate before bundling

Run these checks before sending signedTransaction:

Check	Why it matters
Quote and route still match user intent	A signed transaction can become stale if the user, route, amount, or slippage decision changed
Transaction is fully signed	The bundle endpoint is a submission surface, not a signer
Blockhash is fresh	Stale blockhashes can fail even when the bundle request shape is valid
Fee and priority-fee policy is intentional	Execution settings should be a product decision, not an accidental default
Your app can track `bundleId` and `txId`	Operators need these values when debugging submission or landing issues

If the transaction was built through the older v1 Swap endpoint, keep the v1 parameter family on that build step. If it came from Q1, keep the Q1 request shape on the quote step and treat this endpoint only as the signed-transaction submission handoff.

Failure patterns

Symptom	Likely cause	First fix
`401` or auth failure	Missing or wrong Swap API key	Send the Swap API key in `X-API-KEY`
`400` before submission identifiers appear	Missing, malformed, or non-URL-encoded `signedTransaction`	Verify the base64 payload and URL encoding
Signing error before this call	The transaction was not ready for submission	Fix the signer flow before calling the bundle endpoint
Transaction expires or does not land	The failure moved into blockhash freshness, network landing, or confirmation tracking	Check the transaction status and refresh/rebuild rather than blindly resubmitting

Use Swap API Errors Reference for request-shape and pre-sign failures. Use Blockhash Expiry Recovery Playbook when freshness or duplicate-send risk is the likely problem.

🔶
Use Txn Bundle as the final signed-transaction submission handoff. For the broader platform path, start at carbium.io and route through API Commands when you need to choose the right Swap API surface.