Data Sources

Data Sources let you bring your own items, users, and interactions into embed so Console, Search, features, ranking, and notifications can use account-owned data.

Start in Console to create a data source and send sample payloads. Use the API when you are ready to automate ingestion from your backend.

Console workflow

In Console, open Data Sources to create and monitor account-owned data sources. After a data source is provisioned, expand the row to use:

• Endpoints: copy the public ingestion endpoints for users, items, and interaction events.
• Browse: inspect recently ingested items, users, user interactions, item interactions, and configuration records.
• Send sample payload: choose an entity, optionally mark it as an interaction, load a template, edit the JSON, and submit it to the selected data source.

Console may call internal /api/data_sources/* proxy routes while rendering these controls. Those routes are not public integration contracts; backend integrations should call the public Datasources below.

Public API Surface

Datasource management endpoints are served from https://api.mbd.xyz/v3/datasources. Ingestion endpoints are served from https://api-us-east.mbd.xyz/v3/datasources, which is the base URL shown in Console's endpoint card.

Record IDs

Use stable, namespaced IDs so records can be updated over time.

{
  "item_id": "article.2026-07-06.market-brief",
  "title": "Market brief",
  "url": "https://example.com/brief"
}

Good IDs are deterministic, unique inside your account, and safe to re-send.

Item Interactions

Use item interactions for events such as impressions, clicks, saves, purchases, trades, or hides.

{
  "user_id": "user.123",
  "item_id": "article.2026-07-06.market-brief",
  "event_type": "click",
  "timestamp": 1762300000
}

session_id can be used when the user is anonymous. Prefer integer Unix timestamps for consistency.

User Interactions

Use user interactions for user-to-user events such as follows, invites, messages, copies, or profile views.

{
  "user_id_from": "user.123",
  "user_id_to": "user.456",
  "event_type": "follow",
  "timestamp": 1762300000
}

The current schema uses user_id_from and user_id_to. Older examples that use a single user_id for user interactions should be updated.

Using Ingested Users in Search

After ingestion, use the Console builder or DSL filters to restrict candidates to account-owned users or wallets.

await mbd.search()
  .index("polymarket-wallets")
  .include().inAppUsers("wallet_address")
  .execute();

For account document matches, use console_account filters when supported by the target index.

Operational Notes

• Send either a single object or an array of objects.
• Keep payloads small enough for retry and observability.
• Make ingestion idempotent by reusing record IDs.
• Validate with a Console sample payload before wiring production jobs.
• Expect downstream availability after the ingestion pipeline batches and indexes the records.