Input & Output
The shared config-key pattern across every operation, and how errors surface
Shared Input Pattern
Every operation on this node takes the same two top-level config keys, plus its own operation-specific fields:
| Key | Required | Description |
|---|---|---|
resource | ✓ Yes | One of message, router, lane. |
operation | ✓ Yes | The operation within that resource, e.g. build. |
Everything else is specific to the chosen resource + operation pair — see that resource's page for the
exact field list. Unlike some other blockchain nodes in this catalogue, there is no single node-wide
network default: router operations take their own network field, while
lane and message operations key on chain selectors directly (a lane spans two
networks, so there's no single "the network" to default).
Shared Output Shape
A successful call returns a JSON object whose shape is documented on each operation's page. There's no additional wrapper envelope beyond what's shown there — the fields listed on each operation's page are the output.
String-Typed Numbers
Chain selectors, token amounts, and fee amounts are always JSON strings in both input and output, never numbers — see Networks and CCIP Concepts for why. Don't parse them as JavaScript numbers in a downstream Transform step; keep them as strings (or parse into a big-integer type) all the way through your workflow.
How Errors Surface
| Error Code | Cause |
|---|---|
MESSAGE_NOT_FOUND | The CCIP API returned 404 for a message/getStatus lookup — no message with that ID. |
CCIP_API_RATE_LIMITED | The CCIP API returned 429 after this node's own retry budget was exhausted. |
CCIP_API_UPSTREAM_ERROR | The CCIP API returned 500/502/503/504. |
This list is deliberately not exhaustive — new CCIP-specific error codes are added as needed, following the
same pattern. A local validation failure (e.g. a malformed address passed to message/build) or an
unconfigured RPC network surfaces as its own distinct error rather than one of the codes above — see
Troubleshooting.
message/build and every CCIP API/on-chain
read are safe to call repeatedly with the same input. But calling this node's output into the Ethereum
ExecutionNode's ccipSend step twice sends two separate messages — this node itself never
prevents a duplicate send, since it never sends anything.