> For the complete documentation index, see [llms.txt](https://use.temporal.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://use.temporal.xyz/nozomi/send-bundle.md).

# Send Bundle

Submit up to four transactions that land together, in order, or not at all.

Submit a group of 1–4 signed transactions as one atomic unit. Either every transaction in the bundle lands in the same slot, in the order you sent them, or none of them lands. Use it when one transaction only makes sense if another one landed first: a setup step followed by a swap, a swap followed by your own backrun, or a position change followed by a cleanup.

Bundles use the same compact binary framing as [Batch Send](/nozomi/batch-send.md). The difference is the guarantee: Batch Send forwards each transaction independently, while Send Bundle delivers the whole group to block builders as one unit.

## Request

| Field        | Value                                                   |
| ------------ | ------------------------------------------------------- |
| Method       | `POST`                                                  |
| Path         | `/api/sendBundle?c=<YOUR_API_KEY>`                      |
| Content-Type | `application/octet-stream`                              |
| Body         | Binary-encoded bundle, 1–4 length-prefixed transactions |

Send Bundle is available on every [regional and auto-routed endpoint](/nozomi/endpoints.md), over `http://` and `https://`.

## Limits

| Constraint              | Value       |
| ----------------------- | ----------- |
| Transactions per bundle | 1–4         |
| Min transaction size    | 66 bytes    |
| Max transaction size    | 1,232 bytes |
| Max body size           | 4,936 bytes |

Members may be legacy, v0 or [v1](/nozomi/transaction-v1.md) transactions; bundles keep the 1,232-byte member limit for every version, unlike Batch Send where v1 members may reach 4,096 bytes. | Duplicate signatures within a bundle | Rejected |

## Wire Format

The body is a concatenation of length-prefixed transactions. No JSON, no base64, no outer count, no separators. Order matters: transactions land in the order they appear in the body.

```
[len_hi][len_lo][tx_bytes...][len_hi][len_lo][tx_bytes...]...
```

Each length prefix is a big-endian `u16` giving the size of the following signed transaction bytes. A zero length, a truncated final transaction, or trailing bytes rejects the whole request.

## Tipping

At least **one** transaction in the bundle must pay a [Nozomi tip](/nozomi/tipping-and-faq.md) of at least your account's minimum (default 0.001 SOL) and never less than 1,001 lamports. The other transactions may be untipped. Tip exemptions do not apply to bundles.

The tip can be in any member, but it is common to put it in the first. Because the tip is an instruction inside your own transaction, you only pay it when the bundle lands. Rotate tip addresses between bundles as you would for single transactions.

## Response

Returns an empty body with `200 OK` when the whole bundle is accepted and queued for delivery. Landing is determined asynchronously; compute and track your signatures client-side before submitting, then confirm on-chain or in the dashboard.

Unlike Batch Send, a bundle is validated **in full before anything is queued**. There is no partial acceptance: any error below means nothing from that request was sent.

| Status | Body                            | Meaning                                                                                                          |
| ------ | ------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| `200`  | empty                           | Bundle accepted                                                                                                  |
| `400`  | `Failed to parse transaction`   | Framing error, more than four members, a duplicate signature, or a transaction whose instructions cannot be read |
| `400`  | `Malformed transaction string`  | A member under 66 bytes                                                                                          |
| `400`  | `Transaction too large`         | A member over 1,232 bytes or a body over 4,936 bytes                                                             |
| `400`  | `Insufficient tip`              | No member pays a recognized tip at or above the minimum                                                          |
| `401`  | `Unauthorized`                  | Missing or invalid API key                                                                                       |
| `403`  | `Forbidden`                     | Your key is not permitted to send bundles, or a member uses a program your key is restricted from                |
| `409`  | `Transaction already confirmed` | A member has already landed on-chain; the bundle can no longer be atomic                                         |
| `429`  | `Too Many Requests`             | Rate limited. Each member consumes one rate-limit token, so a four-transaction bundle costs four                 |
| `500`  | `Internal Server Error`         | Retry                                                                                                            |
| `503`  | `not ready`                     | Bundle delivery is temporarily unavailable on this server; retry against another region                          |

All error bodies are plain text.

## How Bundles Are Delivered

* **Block builders only.** Bundles are delivered to block-builder paths (such as Jito and Harmonic), which are the paths that can guarantee atomic inclusion. They do not go over staked connections or direct-to-leader paths.
* **Nozomi appends its own fee transaction.** You may see one extra small transaction from Nozomi immediately after your members in the block. Your transactions are delivered byte-for-byte as you signed them.
* **Once per builder by default.** A bundle is submitted once to each eligible block builder. If your strategy needs repeated resubmission until the blockhash expires, ask support to configure it for your key.
* **No cross-region forwarding.** Single transactions are cross-forwarded between Nozomi regions; bundles are not. For redundancy, send the same bundle to more than one [regional endpoint](/nozomi/endpoints.md#send-to-multiple-regions) yourself. Rate limits are per region.
* **Deduplication.** Re-sending an identical bundle (same signatures in the same order) shortly after the first is accepted with `200` but not delivered again. A bundle with a different member set or order is treated as new. Once any member confirms, every pending copy of the bundle is dropped and further submissions return `409`.

## Building a Bundle

* Sign every member with the **same recent blockhash** so they expire together. Durable-nonce members are accepted, including bundles where every member uses a durable nonce; see the note on durable nonces in [Tipping → Retries](/nozomi/tipping-and-faq.md#retries).
* Put transactions in the body in the order they must execute.
* Keep each member's compute-unit limit close to what it uses. Bundles compete for block space as a unit.
* Do not include a transaction that may already have landed on its own. If it confirms before the bundle is delivered, the bundle is dropped.

## When to Use

Use Send Bundle when correctness depends on **ordering or all-or-nothing execution** across several transactions. If you simply have several independent transactions to submit, use [Batch Send](/nozomi/batch-send.md): it is lower overhead, has no per-bundle size cap, and lands each transaction on whichever path is fastest.

From a browser, `application/octet-stream` skips the CORS preflight `OPTIONS` request, the same as Batch Send.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://use.temporal.xyz/nozomi/send-bundle.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.