Skip to content
MyStocks Developers
API v1

API v1

Current stable contract

Versioning policyRelease changelog
Sandbox console
Operate

Going Live

MyStocks Partner API

Move from sandbox to a controlled production pilot using the documented environment capability matrix and pre-launch checks across security, reliability, correctness, and observability.

Explore endpoints

2 of 2
GET

/audit

Audit log

Full endpoint documentation
Sandbox availablelistAudit

Returns a cursor-paginated list of API calls made with your live key, ordered newest first. Each entry includes the endpoint path, HTTP method, source IP, user-agent, and timestamp. Use ?limit= and ?cursor= for pagination (see the Pagination section).

Parameters

limitintegerquery

Example: 50

cursorstringquery

Opaque cursor from the previous page's nextCursor field.

beforestringquery

ISO timestamp — return only entries older than this value.

Headers

AuthorizationstringRequired

Bearer sk_sandbox_<your_key> for sandbox requests.

Response fields

entriesobject[]
entries[].idstring
entries[].endpointstring

Example: "/api/v1/partner/users/usr_abc/trade"

entries[].methodstring

Example: "POST"

entries[].ipstring | null
entries[].userAgentstring | null
entries[].timestampstring | null
countinteger
hasMoreboolean
nextCursorstring | null

Response codes

200Paginated audit log entries.

Production begins with a limited Controlled Production Pilot. MyStocks must approve the pilot policy, owners, limits, feature flags, and current reconciliation before production mutations are accepted.

Once your integration is tested, switch to the production endpoints. Operations listed as mirrored use the same public schemas and business rules, but settlement timing, real-money behavior, governance controls, and production-only operations differ as shown below.

SandboxProduction
Base URLhttps://mystocks.africa/api/sandbox/v1/partnerhttps://mystocks.africa/api/v1/partner
API key prefixsk_sandbox_pk_live_
Order executionAccelerated simulated execution; canonical terminal state FILLEDPENDING → FILLED / REJECTED; v1 may emit legacy COMPLETED as an alias for FILLED
Custody settlementVirtual and acceleratedSeparate from execution; tracked as PENDING, SETTLED, or FAILED
Stock prices15-minute-delayed prices; inspect asOf and stalePaid licenses use the current shared quote path, which still reports 15-minute delay. Real-time delivery is unavailable pending feed verification. See implementation status
Wallet fundingAuto $100k on registerAdmin deposits real funds
Register/reset utilitiesPOST /api/sandbox/v1/register and POST /api/sandbox/v1/resetNot available

Onboarding steps

  1. Register with Hosted API, OnPrem or Both and test the supported Sandbox workflows.
  2. Review workspace access. Hosted API/Both partner application approval explicitly approves Hosted Live; OnPrem request approval prepares a separate evaluation lifecycle.
  3. For direct Hosted Live, obtain the appropriate production credential through the approved console and store it securely. For installation production, complete OnPrem readiness and activation. Emails contain instructions and retrieval links rather than installation secrets.
  4. Confirm server authorization, scopes, team/security requirements, commercial entitlements and any applicable controlled pilot. Changing an environment selector or key prefix never grants access.
  5. Set the correct production base URL and credential, then test the intended operation and error handling. Sandbox-only utilities and unsupported master /trade and /payout require workflow-specific validation; switching environments alone is insufficient.
  6. Monitor canonical execution state through order queries or signed events, then reconcile settlement separately. Exchange hours, instrument eligibility and provider processing affect execution; do not treat a target as a guaranteed fill time.

Pre-launch checklist

Security

  • API key stored in environment variables — never committed to source control.
  • Webhook endpoint validates the HMAC-SHA256 signature using timingSafeEqual before processing events.
  • Sub-account IDs treated as internal identifiers — never exposed directly to end-users.

Reliability

  • Idempotency-Key set on every authenticated POST/PATCH/PUT/DELETE request except the documented auth/portal exceptions.
  • Exponential backoff implemented for 429 and 500 responses.
  • Webhook endpoint returns 2xx within 8 seconds; heavy processing deferred to a background queue.
  • Webhook delivery failures reconciled from the deliveries endpoint or partner dashboard.

Integration correctness

  • All sandbox scenarios passed: BUY, SELL, insufficient funds, KYC rejection.
  • Order status polling (or webhook) handles WORKING, PENDING, PARTIALLY_FILLED, FILLED, REJECTED, CANCELLED, and EXPIRED; v1 COMPLETED is normalized to FILLED.
  • FX rate recorded on each deposit and withdrawal for your own audit trail.
  • Sub-account KYC tier verified before allowing trades above tier-1 limits.
  • The UI handles INSUFFICIENT_FUNDS (400), KYC_REQUIRED (403), quote conflicts (409), MARKET_CLOSED (422), and RATE_LIMITED (429) by error.code.
  • Sandbox quotes are labelled “15-minute delayed”; paid quotes also retain the current 15-minute delay. Display asOf, stale and quality metadata; do not relabel the current delayed shared path merely because the license is paid.
  • Every stock can fall back to an EOD line chart; candlesticks and volume are enabled only when the candle quality metadata supports them.

Observability

  • Audit log (GET /audit) integrated into your compliance reporting.
  • Usage analytics (GET /usage) monitored to stay within your rate-limit tier.
  • Alert configured when X-RateLimit-Remaining drops below 20% of your tier ceiling.

Was this page useful?

Your signal helps us tighten partner onboarding docs.

Send note

Last updated on

On this page