> 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-responses.md). # Responses & Retries [Endpoints, Account UUID, and rate limits](/node1-docs/robinhood/robinhood-landing.md). The local acknowledgements below apply to the updated nodes across JSON-RPC single transactions, plain text, and batches. ## Single transaction: HTTP 202, queued The node responds after local validation, authentication, rate checks, and queue admission, without waiting for a sequencer response or chain receipt. The response header is `x-node1-submission-state: queued`, and JSON-RPC `result` contains the locally computed transaction hash: 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": 1, "result": "0x", "message": "Successfully forwarded" } ``` This is a normal acknowledgement without `error`, not the former `202 / -32008` response. Clients must not require HTTP 200 to recognize acceptance. JSON-RPC preserves the request `id`; plain text always returns `"id": null`. `queued` acknowledges local acceptance only. It does not guarantee that any or all forwarding paths have completed their writes, or that the transaction was accepted upstream, included in a block, or executed successfully. Subsequent upstream errors such as `nonce too low` are no longer returned through this response. Query your own chain RPC by hash; do not automatically resend just because a receipt is not yet available. A duplicate recognized on the same node may return the same hash with `x-node1-duplicate: true`. This does not acknowledge another forwarding attempt or block inclusion. ## Batch: HTTP 202 and per-transaction status The service persists a local batch receive record, completes rate checks and queue admission, and then responds. Records are uploaded to the database asynchronously; the response does not wait for the sequencer. It contains `result.batch_id` and `result.transactions` ordered by `tx_index`, with an `x-node1-batch-id` header. Example with one transaction item: ```json { "jsonrpc": "2.0", "id": 2, "result": { "batch_id": "", "transactions": [ { "tx_index": 0, "tx_hash": "0x", "status": "queued", "duplicate": false, "retry": "do_not_retry_automatically", "message": "Successfully forwarded" } ] } } ``` Inspect each item's `status`, `retry`, and optional `error`. `queued` means local acceptance; `duplicate` indicates a deduplication hit. HTTP 202 does not guarantee that all items were admitted or succeeded. New requests can be mixed with existing deduplicated items, so do not inspect only the HTTP status. Only retry items explicitly marked `not-sent` and `retry_safe`, after waiting. Do not automatically resend `queued` items or the entire batch. A batch receive record is not proof of block inclusion. ## Local errors | HTTP status | Meaning and action | | ----------- | --------------------------------------------------------------------------------------------------------------- | | 400 | Invalid request parameters or failed local transaction validation; inspect `error` and correct the request | | 401 | Missing Account UUID or failed authentication | | 413 / 415 | Request too large or unsupported Content-Type | | 429 | Account or IP-level request limit reached; follow `Retry-After` and wait | | 503 | Service unavailable, insufficient capacity, or batch recording failure; inspect the error and per-item statuses | Account rate limits use JSON-RPC code `-32005` and may also provide `x-ratelimit-retry-after-ms`. Insufficient capacity may return `-32006`; an explicitly unsent transaction may return `-32001`. Failure to persist the local batch receive record returns `503 / -32011`, before sending transactions from that request. A batch HTTP 503 may contain a top-level `error` or per-item errors inside `result.transactions`. Do not discard the body or resend an entire batch just because the HTTP status is 503. If the connection closes, the response is incomplete, or there is no explicit unsent indication, follow the timeout guidance below. ## Connection timeouts and retries For all three formats, use the hashes of your locally signed transactions to reconcile if no complete response arrives. A transaction or receipt not being found yet is not proof that nothing was sent. Do not automatically resubmit; use your chain RPC to determine transaction status. To maintain connections, see [the 60-second idle timeout and heartbeats](/node1-docs/robinhood/robinhood-landing.md). ## Legacy responses during migration DNS caches or existing connections may still reach older nodes. Clients should distinguish these responses: | Response | Meaning | | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | HTTP 202 + result hash, submission state `queued` | Updated node: locally accepted | | HTTP 200 + result hash | Older node: at least one upstream acknowledged acceptance; not proof of inclusion | | HTTP 202 + `error.code: -32008` | Older node: uncertain outcome; reconcile using `error.data.tx_hash`, without automatically resending | Older batch responses may use HTTP 200/202 with per-item `dispatched`, `in-flight`, `unknown`, or error statuses. Inspect each item's `retry`; an HTTP 2xx response alone does not mean all transactions succeeded. --- # 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-responses.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.