MEV relay Data API passthrough

This endpoint proxies the read-only Data API of the upstream MEV-Boost relay pool. A request to /v1/eth/mev/relay/{relay_id}/{subpath} selects one relay by its short id and forwards your GET to that relay's Data API, returning the relay's JSON response body unchanged. Use it to inspect which payloads a relay delivered to proposers, which builder blocks a relay received, the validator registrations a relay holds, and a relay's liveness status — without having to discover, reach, or authenticate against each relay yourself.

Only a fixed whitelist of read-only Data API sub-paths is reachable; there is no write path here. Submitting bundles or blocks goes through the separate private RPC forwarder and block-builder endpoints, not this mirror. Responses are returned byte-for-byte from the relay (no fields are added, trimmed, or reordered), so you can treat them exactly as you would the relay's own Data API.

Two gotchas worth knowing up front:

• Only GET is accepted. Any other method returns 405.
• The set of relay_id values is configuration-driven. A relay is reachable only if the platform has it provisioned with bid-trace support. An unknown or unprovisioned id returns 404.

Path parameters

200 OK with the relay's JSON body passed through unchanged. For proposer_payload_delivered this is an array of bid-trace objects:

The eth/v1/builder/status sub-path returns 200 with an empty body when the relay is healthy.

This endpoint emits two kinds of error body. Platform-level checks (auth, rate limiting) use the shared Triport error envelope (error / message / request_id). The passthrough handler's own checks return a compact {"error": "<code>", "code": <http_status>} body.

Passthrough error body example (403):

{ "error": "tier_locked", "code": 403 }

See Errors for the full shared envelope, the 429 rate-limit headers, and 401 vs 403 semantics.

JavaScript (fetch)

const relay = "flashbots";
const subpath = "relay/v1/data/bidtraces/proposer_payload_delivered";
const url = `https://api.triport.io/v1/eth/mev/relay/${relay}/${subpath}?slot=7654321&limit=10`;


const res = await fetch(url, {
  headers: { "x-token": process.env.TRIPORT_API_KEY },
});


if (!res.ok) {
  const err = await res.json();
  throw new Error(`relay passthrough failed: ${err.error ?? res.status}`);
}


const traces = await res.json();
console.log(`${traces.length} delivered payloads`, traces[0]?.value);

TypeScript SDK (@triport/sdk)

import { Triport } from "@triport/sdk";


const client = new Triport({ token: process.env.TRIPORT_API_KEY! });


const traces = await client.eth.mev.relay.bidtraces.proposerPayloadDelivered("flashbots", {
  slot: 7654321,
  limit: 10,
});


for (const t of traces) {
  console.log(t.block_number, t.value);
}

Python (triport-sdk)

import os
from triport import Triport


client = Triport(token=os.environ["TRIPORT_API_KEY"])


traces = client.eth.mev.relay.bidtraces.proposer_payload_delivered(
    "flashbots",
    slot=7654321,
    limit=10,
)


for t in traces:
    print(t["block_number"], t["value"])

• Read-only. Only the four whitelisted Data API sub-paths are reachable. Submitting transactions/bundles privately or sending blocks to a builder are separate endpoints, not this mirror.
• GET only. POST/PUT/etc. return 405 method_not_allowed.
• Pagination is the relay's own: pass cursor (a slot) and limit to walk back through historical bid traces; both are forwarded unchanged.
• Relay discovery. The available relay_id values depend on the configured relay pool. If a relay is not provisioned with bid-trace support you'll get 404 relay_not_found rather than a passthrough.
• Responses are unmodified. Bodies are returned exactly as the relay sends them, with only transport headers normalised — do not assume Triport-specific fields.
• Related: Authentication · Rate limits & tiers · Errors.