Home › Broker Integration Guide

Broker Integration Guide

Aggiornato: June 2026

Questa pagina non è ancora completamente tradotta — viene mostrata la versione inglese. English.

A technical one-pager for integrating OptionProfit's strategy engine with your trading API. The flow: your client builds a strategy → we hand you a normalized multi-leg order → you place it. You own auth, execution, funds and compliance. Prefer to talk first? See For Brokers.

▶ Try it live: the broker sandbox runs our engine inside a mock broker — payoff, the Greeks, probability and order-mapping drawn from the real /v1 API, no signup.

Architecture

Three layers, one hand-off:

  Client
    |  builds / picks a strategy (embedded widget or our API)
    v
  OptionProfit  -->  normalized multi-leg order (JSON)
                       |  over your transport (REST / WebSocket / MQTTS / NATS / gRPC / FIX)
                       v
                     Your API  -->  routes under the client's OAuth  -->  Client account

OptionProfit is the analysis + order-building layer. Your platform receives a broker-agnostic order object and executes it. We never hold funds or long-lived credentials.

The order object

One normalized, broker-agnostic payload. Example — an iron condor on AAPL:

{
  "schema": "optionprofit.order/v1",
  "idempotency_key": "op_7f3c1a9e",
  "account_ref": "{broker-account-token}",
  "underlying": "AAPL",
  "strategy": "iron-condor",
  "order_type": "net_credit",
  "limit_price": 1.85,
  "time_in_force": "day",
  "quantity": 1,
  "legs": [
    { "action": "sell", "type": "put",  "strike": 190, "expiry": "2026-08-21", "ratio": 1 },
    { "action": "buy",  "type": "put",  "strike": 185, "expiry": "2026-08-21", "ratio": 1 },
    { "action": "sell", "type": "call", "strike": 210, "expiry": "2026-08-21", "ratio": 1 },
    { "action": "buy",  "type": "call", "strike": 215, "expiry": "2026-08-21", "ratio": 1 }
  ]
}

Field notes. action = buy|sell · type = call|put · order_type = market|limit|net_debit|net_credit · legs carry OCC/OSI-style strike + expiry and a ratio for uneven spreads. We map to your symbology (OCC, OSI, or your own option ids) during onboarding.

Delivery over any transport

The same order object, your protocol — you keep your existing order-routing structure:

REST       POST {your-base}/orders          Authorization: Bearer {client-token}
WebSocket  send { "type":"place_order", "order": { ... } }
MQTTS      publish  broker/{account}/orders  (TLS + client certificate)
NATS       publish  orders.place             (NATS JWT / nkey creds)
gRPC       rpc PlaceOrder(Order) returns (OrderAck)
FIX        New Order - Multileg (MsgType = AB), legs in the NoLegs group

We ship a small reference adapter for your transport; you keep full control of routing, risk checks and execution.

Auth

OAuth 2.0 on your side. The client authorizes order placement to their own account; we receive only the short-lived, order-scoped token you issue — never a password, never funds. Token refresh and revocation stay under your control.

Confirmation & idempotency

Every order carries a client-generated idempotency_key, so a retry never double-places.
We relay your OrderAck (accepted / rejected / filled) back to the client.
Nothing is submitted without an explicit client confirm step — we build the order; the client presses place.

What we need from you

Your order API + preferred transport + option symbology.
OAuth details (authorize/token endpoints, scopes for order placement).
Sandbox credentials to test against.

We integrate against your sandbox and hand you a reference adapter before any live order flows.

Privacy by architecture — we never see your customers

The /v1 API is feed-agnostic and stateless: your request carries only market data — an underlying price, days to expiry, an IV, and the option legs or chain (strikes, premiums, quantities). We return the analytics and keep nothing. No customer name, account number, email or any PII ever crosses the API — there is no field for it and no need for one.

That is a clean separation of concerns, and it does real work for your compliance team:

Identity stays with you, the regulated party. You already do KYC; we only ever see the position, never who holds it. "They can't leak our customers because they never receive them" is the shortest vendor security review you'll run.
GDPR — on this path there is no personal data to process, so the usual Data Processing Agreement / sub-processor negotiation over customer data simply doesn't apply.
DORA / third-party risk — one fewer external party touching customer data is one fewer entry in your ICT third-party-risk register.
Aligned by the business model. We bill per computation (€0.01/leg), never per profile — so we have no reason, ever, to start collecting. The data-lessness is the design, not a policy that could change.

Security & scope

Analysis and order-building only. You keep execution, funds, KYC/suitability and every regulatory obligation. All traffic is encrypted in transit (TLS/HTTPS/HSTS); see our Security & Trust page. OptionProfit is an independent educational tool — not a broker and not a financial adviser.

Certification. Desego BV is certified against Cyber Fundamentals (CyFun) — the Belgian national cybersecurity framework, maintained by the Centre for Cybersecurity Belgium and designed to map onto NIS2. For your third-party-risk register and DORA due diligence, we can share the certificate — with its assurance level and scope — on request. Combined with the data-less architecture above, that's a certified security baseline against a recognised national framework — on a vendor that never receives your customers' personal data.

Start the integration

Send your API docs (and sandbox access if you have it) to partnerships@options-strategies.com. We'll return a scoped integration plan and the reference adapter for your transport. General enquiries: For Brokers · contact.

Chi siamo · Lavora con noi · For brokers · Contatti · Methodology · Avvertenze · Informativa sulla privacy · Politica sui cookie (UE) · Termini e condizioni · Security · Home