Deploying Data Proxies

This page guides you through deploying a data proxy on the SEDA Network to consume private or proprietary data without revealing secrets.

Define Your Data Source

Canonical URL: https://docs.seda.xyz/home/for-agents/agent-modules/deploying-data-proxies

Source file: modules/10-data-access.md (label only, do not fetch)

Authoritative entry:

• https://docs.seda.xyz/home/for-developers/define-your-data-source

Your job on this page is to decide:

• where the data comes from

• whether you need a Data Proxy

• what the Oracle Program will consider a valid response

Rule: If a value is not explicitly provided by docs or config, stop and ask.

---

1) Supported feeds

Use when:

• a feed already exists in SEDA’s supported catalog.

Action:

• identify the feed (provider + symbol)

• decide if you need custom logic (smoothing, fallbacks, blending)

  • if yes, you still build a custom Oracle Program

Checkpoint:

• you can name the provider/feed and the exact output fields you expect.

---

2) Public API

Use when:

• the endpoint requires no credentials.

Action:

• confirm response format (JSON preferred)

• define parsing rules and validation rules (schema, bounds, freshness)

• read timeout defaults and set per-request timeout if needed:

  • modules/12-http-fetch-timeouts.md

Checkpoint:

• you can state the JSON path(s) you will parse and the bounds you will enforce.

---

3) Private API / proprietary data

Use when:

• upstream requires API keys, tokens, cookies, or internal access.

Rules:

• do not embed secrets in Oracle Program code or repos

• use a Data Proxy route to hold credentials and enforce access/proof

Next:

• modules/25-data-proxy.md (deploy + route + register + validate + run)

Checkpoint:

• you can describe your intended proxy route shape:

  • baseURL, routeGroup, path, and upstream URL mapping.

---

4) Website-only source

Use when:

• no stable API exists and you rely on scraping or a “website-to-API” service.

Rules:

• treat it as private/proprietary behind a proxy route

• plan for breakage (define fallbacks or fail-closed behavior)

Next:

• modules/25-data-proxy.md

Checkpoint:

• you can name at least one fallback source or a defined “fail closed” behavior.

---

Recommended output contract

Before writing code, define:

• source: provider + endpoint domain

• fetched_at: timestamp requirement (freshness)

• payload_hash: hash of raw payload

• parsed_result: normalized fields your OP outputs

• validation: schema + bounds + freshness rules

This prevents ambiguous Oracle Programs that are hard to verify.