METHOD

API Review Methodology

A weighted, evidence-based process for comparing Trader APIs without turning unknowns into confident scores.

API review methodology

Evidence before scores

TraderAPI.com evaluates an API against a defined workflow. A market-data application and an execution service should not use the same weights. The methodology records requirements, evidence, tests, unknowns, and operational risks before any summary conclusion.

A provider is not awarded a capability because a similar product has it or because an old tutorial mentions it. Current interface, account, product, and regional context must be identified.

Evidence recordMETHOD

{
  "requirement": "specific workflow need",
  "evidence": "primary source or test",
  "environment": "sandbox or production",
  "result": "pass, fail, partial, unknown",
  "risk": "impact and mitigation",
  "reviewed": "date + reviewer"
}

Review dimensions

Ten weighted categories

Workflow fit

Asset class, account context, user type, deployment model, and intended responsibility.

Data model

Identifiers, fields, numeric units, timestamps, sessions, status, corrections, and history.

Protocols

REST, streaming, session behavior, subscriptions, heartbeats, sequence, replay, and recovery.

Execution

Validation, order types, state, idempotency, fills, rejection detail, replace, cancel, and reconciliation.

Security

Credential issuance, scopes, signing, expiry, IP controls, rotation, revocation, and audit events.

Reliability

Maintenance, degraded modes, unknown state, backfill, limits, monitoring, and support escalation.

Testing

Sandbox fidelity, paper behavior, fixtures, replay, contract tests, and failure scenarios.

Documentation

Coverage, versioning, examples, change notices, error detail, SDK maintenance, and clarity.

Rights and cost

Subscriptions, professional classifications, display, storage, redistribution, fees, and engineering effort.

Governance

Ownership, decision log, risk acceptance, production approval, periodic review, and migration plan.

Scoring

Unknown is not average

Each requirement receives a result—pass, partial, fail, or unknown—and a confidence level based on evidence. Unknown items remain visible and can block production when they affect security, order state, money movement, data rights, or recovery.

Weights reflect the application. Documentation quality may be important to every team, while market depth or paper trading may be essential only to some. Final decisions include the highest-risk unknowns and the tests required to resolve them.

A score summarizes evidence. It does not replace the evidence.