Accessing Data On SEDA

Choose and specify your data source (supported feeds, public API, private API, website-only) and determine when a Data Proxy is required.

Define Your Data Source

Canonical page: https://docs.seda.xyz/home/for-agents/modules/10-data-access 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

Browse Supported Feeds

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.


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.

Last updated

Was this helpful?