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.
Last updated
Was this helpful?
Choose and specify your data source (supported feeds, public API, private API, website-only) and determine when a Data Proxy is required.
Canonical page: https://docs.seda.xyz/home/for-agents/modules/10-data-access
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.
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.
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: https://docs.seda.xyz/home/for-agents/agent-modules/http-fetch-timeouts
Checkpoint:
you can state the JSON path(s) you will parse and the bounds you will enforce.
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:
https://docs.seda.xyz/home/for-agents/agent-modules/deploying-data-proxies (deploy + route + register + validate + run)
Checkpoint:
you can describe your intended proxy route shape:
baseURL, routeGroup, path, and upstream URL mapping.
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:
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?
Was this helpful?