Partner Integration Security Architecture

This page focuses on how a partner should design a secure 6MM integration. For the broader security layers used across the trading platform, see Platform Security Architecture.

Security architecture should be agreed before production integration begins. It affects how partner systems validate users, issue tokens, store secrets, receive events, monitor operations, and respond to incidents.

Recommended trust boundary

Component	May contain	Must not contain
Partner frontend	Public configuration, short-lived entry result, non-sensitive UI state	Partner API secret, signing key, privileged backend credentials
Partner backend	User mapping, protected credentials, signing logic, webhook processing	Secrets exposed through client responses or public logs
6MM integration endpoints	Approved signed requests, tokens, and webhook delivery	Unverified partner-side user assumptions

The partner frontend should call the partner backend for privileged operations. The backend validates the partner user, calls 6MM through the approved API or SDK, and returns only the short-lived result needed by the frontend.

Security layers

Layer	Required focus
API credentials	Backend-only storage, rotation plan, and access control.
Request signing	Consistent timestamp, signature, and replay protection handling.
Embed tokens	Short-lived issuance, eligibility checks, and clear invalidation behavior.
Webhooks	Signature verification, idempotency, retries, and event audit logs.
Operations	Access roles, incident escalation, monitoring, and evidence retention.

Production control plan

Control area	Minimum implementation evidence
Credential storage	Secret-manager location, access owner, environment separation, and rotation process.
User entry	Session validation, eligibility check, short-lived token flow, and failure handling.
Signed requests	Correct environment, synchronized time, request logging, and signature-error alerts.
Asset operations	Unique business IDs, timeout reconciliation, status queries, and operator review path.
Webhooks	Raw-body signature verification, replay controls, idempotency store, and retry-safe processing.
Monitoring	Alerts for authentication failures, abnormal retries, webhook lag, and operational errors.
Incident response	Named owner, escalation channel, evidence retention, and credential-revocation procedure.

Launch review

Before production:

Draw the user, token, request, asset, and webhook data flows.
Mark where every credential is created, stored, used, logged, rotated, and revoked.
Test expired tokens, invalid signatures, timeouts, duplicate webhooks, and reconnect behavior.
Confirm that support teams can locate an operation from its request or business identifier.
Complete the Production Launch Checklist.

Recommended docs

Secrets & Signing

Protect Agent SDK credentials and signed requests.

Request Signing

Implement direct Developer API request signing.

Webhook & Idempotency

Process events safely.