Client Guide

Market + Event Study APIs

Practical, end‑to‑end examples for new users and enterprise clients. Covers authentication, real‑world workflows, and production tips.

Who this guide is for

New end users

Get a token and run your first Market risk index or Event Study request in minutes.

Enterprise clients

Understand product scoping, authentication boundaries, and production deployment considerations.

Authentication model (product‑scoped)

Each product is isolated. Tokens are scoped to a single product and cannot cross product boundaries.

Authorization: Bearer <product-scoped-token>

Use /api/v1/market/auth/* for Market tokens and /api/v1/eventstudy/auth/* for Event Study tokens.

Real‑world example: Daily risk monitoring (Market)

Scenario: a treasury team wants a simple market risk signal at open and before close.

Authenticate as a Market user.
Call the risk index endpoint twice per day.
Store the numeric risk_score for internal alerts.

curl -s -X POST https://api.mysignalflow.io/api/v1/market/auth/login \
        -H "Content-Type: application/json" \
        -d '{"email":"you@company.com","password":"your-password"}'

curl -s https://api.mysignalflow.io/api/v1/market/riskindex \
  -H "Authorization: Bearer <market-token>"

A typical response includes vix, risk_score, and level (Low/Moderate/High).

Real‑world example: Event impact analysis (Event Study)

Scenario: an enterprise client wants to quantify the impact of an earnings release on a stock.

Authenticate with an Event Study account.
Submit the symbol and event date.
Use the returned series and stats to brief stakeholders.

curl -s -X POST https://api.mysignalflow.io/api/v1/eventstudy/auth/login \
        -H "Content-Type: application/json" \
        -d '{"email":"you@company.com","password":"your-password"}'

curl -s -X POST https://api.mysignalflow.io/api/v1/eventstudy \
  -H "Authorization: Bearer <eventstudy-token>" \
  -H "Content-Type: application/json" \
  -d '{"symbol":"AAPL","event_date":"2024-01-02"}'

The response includes event‑window series and summary statistics (abnormal returns, significance metrics).

Professional case scenario: Portfolio oversight in a regulated environment

Scenario: a buy‑side firm runs daily oversight for a multi‑asset portfolio. They need a consistent market risk signal for trading gates, plus event‑level attribution when volatility spikes.

Stakeholders

Risk lead, portfolio manager, compliance officer.

Data inputs

Daily holdings snapshot, earnings calendar, internal event list.

Outputs

Risk index trend, event‑window abnormal returns, audit log of decisions.

At 08:30 ET, the risk team requests the Market risk index and compares it to a governance threshold.
If the threshold is exceeded, compliance requests an Event Study on the top three positions with known events.
Results are exported to the firm’s oversight dashboard and stored for audit review.

# 1) Market risk index (oversight gate)
curl -s https://api.mysignalflow.io/api/v1/market/riskindex \
  -H "Authorization: Bearer <market-token>"

# 2) Event Study for top positions (example)
curl -s -X POST https://api.mysignalflow.io/api/v1/eventstudy \
  -H "Authorization: Bearer <eventstudy-token>" \
  -H "Content-Type: application/json" \
  -d '{"symbol":"MSFT","event_date":"2024-01-30"}'

This pattern supports governance: Market provides a gate, Event Study provides explanation, and both remain product‑scoped for audit clarity.

Professional case scenario: Corporate treasury risk committee

Scenario: a global corporate treasury team reviews risk weekly and needs a defensible, repeatable signal for hedging decisions and board reporting.

Stakeholders

Treasury lead, CFO delegate, risk committee, internal audit.

Data inputs

FX exposures, interest‑rate sensitive cash flows, scheduled macro events.

Outputs

Risk index trend, event‑window evidence, committee decision log.

Before the committee meeting, treasury pulls the Market risk index to benchmark current conditions.
For any scheduled policy announcements, treasury runs Event Studies to quantify impacts on key instruments.
Results are packaged into a brief and stored with an audit trail for governance review.

# 1) Market risk index (committee prep)
curl -s https://api.mysignalflow.io/api/v1/market/riskindex \
  -H "Authorization: Bearer <market-token>"

# 2) Event Study around policy event (example)
curl -s -X POST https://api.mysignalflow.io/api/v1/eventstudy \
  -H "Authorization: Bearer <eventstudy-token>" \
  -H "Content-Type: application/json" \
  -d '{"symbol":"TLT","event_date":"2024-03-20"}'

This workflow keeps hedging decisions evidence‑based and traceable while preserving product isolation.

Enterprise deployment tips

Issue separate credentials per product and environment (staging vs production).
Rotate tokens regularly; keep Market and Event Study credentials isolated.
Place calls server‑side for compliance workflows; avoid sharing bearer tokens client‑side.
Use a service account per team to simplify audits.

If you need long‑running automation, ask for a service account and configure rotation in your secrets manager.

Engine delivery models (confidential artifacts)

Market and Event Study engines are confidential binaries. Choose the distribution model that matches your security posture.

1) Download‑on‑demand (recommended)

You receive a signed manifest from Everline, then download the signed artifact on first deploy.

# Example layout on the client machine\n/opt/mysignalflow/engines/bin/market_engine\n/opt/mysignalflow/engines/bin/eventstudy_engine\n/opt/mysignalflow/engine_manifests/*.json\n\n# Environment configuration\nMSF_ENGINE_MANIFEST_DIR=/opt/mysignalflow/engine_manifests\nMSF_TRUSTED_MANIFEST_KEYS=prod:key-1,prod:key-2\nMSF_TRUSTED_ARTIFACT_KEYS=prod:key-1,prod:key-2\nMSF_TRUST_MIN_KEYS=2

2) Private package distribution

Engines are delivered through a private registry or secured download link. Artifacts stay encrypted in transit.

# Example package install (illustrative)\n# 1) Authenticate with the private registry\n# 2) Install the engine bundle\n# 3) Verify signatures locally\n\nMSF_ENGINE_MANIFEST_DIR=/opt/mysignalflow/engine_manifests\nMSF_TRUSTED_MANIFEST_KEYS=prod:key-1,prod:key-2

3) Air‑gapped delivery

Engines are shipped as a signed offline archive. You verify signatures before placing artifacts on the runtime host.

# Offline verification (illustrative)\nsha256sum /media/usb/market_engine\ncat /media/usb/market_engine.sig\n\n# Place artifacts\n/opt/mysignalflow/engines/bin/market_engine\n/opt/mysignalflow/engine_manifests/market_engine.json

All three models use the same local verification steps: signed manifest + signed artifact + trusted key policy.

Support

For onboarding assistance or enterprise SLAs, contact your Everline account manager.