Market Lifecycle, Resolution & Alerts

This page covers state transitions, resolution payloads, and monitoring signals.

Use it to keep downstream systems correct as markets open, halt, resolve, and settle.

API conventions

These routes are read-oriented. They are designed for analytics, monitoring, and automation.

• Auth: Authorization: Bearer $ACCESO_API_KEY

• Base URL: https://<YOUR_ACCESO_API_HOST>

• Response envelope: stable success / data / meta

Example: response envelope (shape)

{
  "success": true,
  "data": {},
  "meta": {
    "request_id": "req_1c2d3e",
    "timestamp": 1765939200
  }
}

• Normalization: timestamps are epoch seconds. IDs are opaque strings.

• Pagination (when available): limit, cursor (opaque), direction=asc|desc (route-dependent)

• Freshness: sources can be eventually consistent. “Latest” routes may be briefly cached.

Always treat cursor as opaque. Cursor semantics are endpoint-specific.

Lifecycle model

Vendors expose different state machines. Acceso maps them into a small, stable lifecycle model.

Normalized states (typical)

• created

• open

• halted (temporary stop)

• closed (no longer trading)

• resolved (final outcome known)

• settled (finalized settlement completed)

What you typically get

• market_id

• state

• key timestamps (when known):

  • created_at

  • open_at

  • close_at

  • resolved_at

  • settled_at

• reason (optional, for halts or closure)

Some markets do not publish every transition time. Treat timestamps as best-effort.

---

Resolution and outcomes

Resolution payloads are designed for auditability and downstream correctness.

What you typically get

• market_id

• resolved (boolean)

• resolved_at

• winning_outcome_id (or equivalent)

• winning_outcome_label (when available)

• resolution_source / resolution_url (when available)

• notes (optional)

Resolution can be corrected upstream. Handle updates as idempotent. Persist the latest values rather than assuming “final means immutable”.

---

Alerts and monitoring

Alerting helps you react to important changes without polling.

Common alert types:

• market.state_changed

• market.resolved

• market.price_moved (absolute or % threshold)

• market.volume_spike (windowed anomaly)

Delivery options

Delivery is deployment-dependent. Common patterns:

• webhooks (push to your endpoint)

• streaming feeds (when enabled)

Recommended workflow

1. Subscribe to the markets or a filter (category, query).

2. Validate webhook signatures (if enabled in your deployment).

3. Store event_id and dedupe.

4. Reconcile by fetching the latest market snapshot on every event.

Alerts are signals, not source of truth. Always reconcile with a read endpoint.