> For the complete documentation index, see [llms.txt](https://node1.gitbook.io/node1-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://node1.gitbook.io/node1-docs/robinhood/robinhood-landing/robinhood-send-plaintext.md). # Send Plaintext Transaction [Endpoints, Account UUID, and rate limits](/node1-docs/robinhood/robinhood-landing.md). Bots and browser applications can submit the same signed transaction directly as a text body, without a JSON-RPC request envelope. This endpoint supports single transactions only. ```http POST /v2/robinhood_send_raw_transaction?auth= Content-Type: text/plain ``` The body must contain one complete `0x`-prefixed signed transaction, without JSON, quotes, or an array. Leading and trailing ASCII whitespace are allowed. Transaction formats, validation, and the node's configured body-size limit are the same as for JSON-RPC. ## cURL: Account UUID in the URL ```bash curl -X POST 'https://robinhood-ohio-2b.node1.me/v2/robinhood_send_raw_transaction?auth=' \ -H 'Content-Type: text/plain' \ --data-raw '0x' ``` Replace both placeholders with your own values, remove the angle brackets, and keep a single `0x` prefix. To use Ohio 2C or SFO3, replace only the hostname with the corresponding hostname in the [service overview](/node1-docs/robinhood/robinhood-landing.md). ## cURL: Account UUID in the Authorization header Bots may instead omit the query string and use Bearer authentication: ```bash curl -X POST 'https://robinhood-ohio-2b.node1.me/v2/robinhood_send_raw_transaction' \ -H 'Authorization: Bearer ' \ -H 'Content-Type: text/plain' \ --data-raw '0x' ``` Use exactly one authentication method. When using URL authentication, provide one `auth` parameter and no other query parameters; URL-encode its value. Requests with both authentication methods, duplicate parameters, or malformed URL encoding are rejected. URL authentication is specific to this endpoint. Keep UUIDs out of shared URLs and redact `auth` in your own request logs. ## Browser example ```javascript const response = await fetch( `${baseUrl}/v2/robinhood_send_raw_transaction?auth=${encodeURIComponent(accountUuid)}`, { method: 'POST', headers: { 'Content-Type': 'text/plain' }, credentials: 'omit', body: signedRawTransaction, }, ); const result = await response.json(); if (!response.ok || result.error) { // Follow error.data.retry when present; do not automatically retry unknown submissions. console.error(response.status, result.error ?? result); } else { console.log(result.result); // HTTP 202: locally accepted, not included on-chain. console.log(response.headers.get('x-node1-submission-state')); // queued } ``` Set `baseUrl` to one of the HTTPS endpoints in the [service overview](/node1-docs/robinhood/robinhood-landing.md), without a trailing slash. URL authentication with `text/plain` allows a browser request without CORS preflight when no extra headers or other preflight-triggering options are added. Bearer authentication may trigger preflight; this endpoint also supports `OPTIONS`. Cookie credentials are not supported. Browser clients can read the submission-state, duplicate, and retry-after response headers. For server-side bots, there is no browser CORS preflight to avoid. Plain text simplifies the request format; it does not guarantee faster block inclusion. HTTPS still encrypts transport. ## Shared limits and response format The plain-text and JSON-RPC single-transaction endpoints share account quota, free/paid routing, and deduplication on each node. Standard paid accounts also share transaction-based quota with batches; each single request consumes one credit. See [Plans & rate limits](/node1-docs/robinhood/robinhood-landing.md). Switching formats does not grant extra quota or bypass deduplication. Duplicate valid requests still consume quota. Responses remain JSON, with the same single-transaction status codes and error fields described in [Responses & Retries](/node1-docs/robinhood/robinhood-landing/robinhood-responses.md). Since the request has no JSON-RPC ID, the response uses `"id": null`: The display field `message` is `"Successfully forwarded"`. It appears at the top level for single JSON-RPC and plain-text responses, and on each `queued` transaction item in a batch. This is presentation text: the service still returns HTTP 202 after local queue admission, without waiting for socket writes or sequencer acknowledgement. It does not confirm block inclusion. Clients should use the status, hash, and error fields rather than this display text to determine transaction state. ```json { "jsonrpc": "2.0", "id": null, "result": "0x", "message": "Successfully forwarded" } ``` Updated nodes return HTTP 202 immediately after local validation, authentication, rate checks, and queue admission, with `x-node1-submission-state: queued`. They do not wait for a sequencer response or chain receipt. The result hash above acknowledges local acceptance only; subsequent upstream errors are not returned through this response. Clients should accept a normal HTTP 202 result and inspect `error` and submission state. During migration, older nodes may still return a `202 / -32008` error. This differs from a queued acknowledgement; see [Responses & Retries](/node1-docs/robinhood/robinhood-landing/robinhood-responses.md). [Response handling and retry rules →](/node1-docs/robinhood/robinhood-landing/robinhood-responses.md) --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://node1.gitbook.io/node1-docs/robinhood/robinhood-landing/robinhood-send-plaintext.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.