Integration testing
Validate authentication, order handling, exact values and recovery before enabling automated trading.
Start with reads and simulated responses
Validate representative responses against the OpenAPI and realtime schemas used by your client. Begin with market discovery, a book snapshot, market statistics and capability checks. The market-data examples provide a starting point for read-only requests.
Create synthetic or sanitized responses for normal and failure cases. Keep credentials and sensitive account data out of fixtures. Use owner-approved credentials for the test environment supplied for your integration.
Integration validation
Integration validation
Drag to pan, or use arrow keys when the diagram is focused. Use plus and minus to zoom, and zero to fit. On a touch screen, pinch to zoom.
Validate requests and responses against the API schemas, simulate normal and interrupted flows, then test with an authorized account in the target environment. Include connection failures and uncertain order outcomes before enabling automated trading.
Record the API version, environment, client version and relevant device or runtime so results are repeatable. Test order behavior as well as successful connections and message parsing.
Test continuity and stale-state handling
Exercise subscription acceptance, the first snapshot, successive complete book snapshots, duplicate messageId values, out-of-order data, sequence_gap, resync_required, missed heartbeats and reconnection. Confirm that full book snapshots replace levels rather than adding to them.
For private streams, test subscribe-before-auth refusal, ticket replay refusal, ticket rotation followed by auth_ok, missing reauthentication, expiry, revocation and private_subscriptions_dropped. Ongoing public traffic must not make private balances appear current. Test unavailable channels and mark-candle rejection explicitly.
Use the sequence and snapshot metadata returned by the contract. Do not assume ordering across channels or a replay-retention period that the API does not document.
Connection recovery
Connection recovery
Drag to pan, or use arrow keys when the diagram is focused. Use plus and minus to zoom, and zero to fit. On a touch screen, pinch to zoom.
Validate identity before advancing a cursor. Ignore duplicates and older updates that would replace newer state. When continuity is lost, mark the affected view stale and use its supported recovery flow.
Sequence scope. Public envelope sequences can be sparse. Book state, candles and private channels have their own continuity rules; do not compare their cursors as if they formed one global sequence.
Bounded recovery. Define the recovery trigger, permitted requests and retry limit. When recovery cannot restore the required data, preserve a stale state and make the interruption visible.
Replay limits. Private account recovery may require a supported snapshot where replay is incomplete. Recovery must follow the available contract, and reconnecting must not be treated as proof of complete account or closed-position history.
Test credential permissions
With credentials authorized for your test account, verify that read scope permits account inspection and preview while placement is refused with scope_insufficient. Owner-only routes should refuse an API key with passkey_required. Include expired, revoked and wrong-environment credentials.
For device authorization, exercise pending, slow_down, single approval and expiry. For remote MCP, attach the private bearer to every request; a session identifier does not replace authentication. Confirm that logs redact authorization headers and socket-ticket material.
Test order outcomes and retries
Use an authorized account and environment for trading tests, with limits appropriate to your test plan. Cover preview-to-placement field conversion, post-only rejection, reduce-only behavior, price and quantity validation, partial fill followed by cancellation, and mixed batch results.
Simulate a lost response after submission, then retry the original command with the same identities. The client must not create a new logical order. Exercise 429 responses, retryable 503 responses, validation failures and unresolved outcomes. Do not depend on a Retry-After header where the operation does not provide one. Ensure the interface distinguishes accepted, filled, rejected and unresolved states.
Prepare your integration for operation
Confirm supported channels, credential scopes, limits, precision rules and reconnect behavior in the environment you will use. Check that incomplete open-order snapshots and stale history remain visible as incomplete.
Define your response to key expiry, ticket rotation, interrupted data, pending orders and the need for owner intervention. Edel Markets is on Devnet, with Testnet and Mainnet coming soon. Confirm account readiness and supported market-maker operations in your chosen environment. See market-maker operations.
Verify live updates without polling
After initial state acquisition, deliver representative market and account stream messages to your client and count subsequent REST reads. Supported position, mark, PnL, order and fill changes should update the displayed state from the stream payloads without routine account reads.
Test recovery separately from normal operation. An actual gap or unresolved command may require the documented recovery flow; it should not turn every incoming event into a REST request. If the stream contract lacks a required field, show the affected view as stale or unavailable.
Test precision and concurrent outcomes
Test decimal strings beyond JavaScript’s safe integer range and instruments with different price, quantity and collateral scales. Reject unsupported precision rather than silently rounding order amounts. Invalidate previews when the draft, account context or validity period changes.
Replay duplicate, older and wrong-account events, gaps and rejected replay cursors. Exercise fills arriving during cancellation and position changes during a pending close. Preserve the original command identity after an unknown result, and prevent older data from reopening an order already known to be terminal.
Measure functional behavior and performance separately
Use isolated tests for conversions and state updates, simulated responses for interface behavior, and authorized environment tests for real authentication and order flows. A successful simulated response does not establish that the same flow is available in the target environment.
For performance measurements, record workload, duration and the completion boundary. Requests submitted, engine application, durable off-chain commitment and Canton settlement measure different stages. Report those results separately from functional correctness.
Security audits have not yet been completed. Functional and performance tests do not replace an independent security audit. See audit status.