๐Advanced: API-key Gated Data
Certain use cases require access to API endpoints protected by API keys. Given that SEDA is an open protocol, using API keys directly in a Data Request would expose them to the public, which is generally undesirable. To address this issue, SEDA utilizes Data Proxies. These proxies act as intermediaries between the API-key-protected endpoint and the overlay network, allowing only eligible Overlay Nodes to access the proxy. This ensures that unauthorized parties cannot access the API, securely exposing the API-key-protected endpoint without revealing the key.
For more information about Data Proxies and how to set one up, see Data Proxy.
In this walkthrough, we assume that a Data Proxy is already set up, either by you or a Data Provider of your choice.
Calling a Data Proxy Node with proxyHttpFetch
is similar to using httpFetch
, with a key difference in how the Overlay Node handles the request:
It attaches a proof header to the request (
x-seda-proof
), which includes information about the eligibility of the Overlay Node.It verifies the validity of the Data Proxy's signature.
It adds the public key to the Overlay Nodeโs result, which is included in the tally phase.
(Optional) Verifies if the signature belongs to the given public key and throws an error if it is invalid. Note: As a security measure, you should verify the signatures during the tally phase. This is because the tally phase is a deterministic environment that all Chain Validators run, ensuring the data has not been tampered with. Verification during execution does not guarantee against a rogue Overlay Node submitting an incorrect signature.
Let's see how we can use proxyHttpFetch
:
proxyHttpFetch
calls return two headers with every response. You can use these in your execution result, for example, if you want to verify the signatures during the tally phase:
This setup ensures that you can safely call APIs requiring keys, leveraging Data Proxies for secure interaction.
Last updated