API Overview

Seccl offers multiple authentication protocols based on your risk appetite. Our authentication is managed via Okta Auth0

• ClientID & Secret (Default)
  Secure API authentication using industry-standard OAuth 2.0. Credentials are managed through our developer portal with automated key rotation and access monitoring. Suitable for most integrations and development needs
• FAPI
  Financial-grade authentication protocol designed specifically for financial services. FAPI enhances security through advanced OAuth 2.0 specifications, making it ideal for firms requiring additional security assurance or operating under stricter regulatory requirements

Idempotency ensures that repeated API requests don't result in unintended duplicate transactions, providing safety for retries during network issues or timeouts. When making POST, PUT, PATCH, or DELETE requests to Seccl's API, you can include an idempotency key in the request header to guarantee that multiple identical requests will result in only one execution.

To use idempotency, include a UUID v4 formatted key in your request header. If you retry a request with the same key within 72 hours, you'll receive the same response as the original request. This is particularly important for financial operations where avoiding duplicates is crucial. While idempotency keys are optional, we strongly recommend their use for any state-changing operations.

• Atomic operations
  Core financial operations like trades, orders and cash movements are processed atomically, meaning they either complete fully or not at all. This ensures that critical financial data remains consistent and accurate, with no partial or incomplete states
• Eventually consistent operations
  Some operations, such as portfolio valuations and performance calculations, are processed using eventual consistency. These operations may take time to propagate through our systems. For these requests, you'll receive a 202 Accepted response with a resource URL to check the operation's status, and we'll notify you via webhook when processing completes

The platform uses webhooks for comprehensive event notification across all resource interactions. Where possible, webhooks contain the complete resource data, eliminating the need for subsequent API calls to fetch updated information. This includes eventual consistency updates (both success and error states), inbound flows and manual operations such as reconciliation activities (should they arise). Any change to platform resources triggers a corresponding webhook, ensuring systems remain synchronised. Webhook availability can be extended through account management if additional notification needs are identified.

We design our systems to accommodate your reconciliation needs by supporting external reference mapping across all relevant resources. This principle ensures seamless integration between Seccl and your internal systems. Where available this can be sent to us in the following format: 256 characters, alphanumeric, spaces, dashes and underscores only and stored against the resource and available on Webhooks and GET requests.

Our platform scales with your business. Rather than enforcing rigid limits, we design our rate limiting around your specific load patterns and scaling needs. When limits are reached, requests receive a 429 'Too Many Requests' response, along with standard rate limit headers showing current limits, remaining requests and reset timing. We recommend implementing exponential backoff strategies in your applications to handle these. Before going live, please share your expected usage patterns—including peak volumes, daily patterns, and growth projections—so we can configure appropriate limits for your business needs. This approach ensures reliable service delivery while maintaining platform stability for all users.

The platform's APIs support real-time data access as the primary and recommended interaction model. For scenarios requiring large periodic data extracts, such as end-of-day reporting, SFTP-based delivery can be arranged through account managers. This complementary service supports specific business needs while maintaining the platform's focus on real-time API operations.

The platform maintains a single codebase, focusing on continuous evolution rather than maintaining multiple API versions. This approach ensures all clients benefit from the latest improvements while providing clear migration paths for changes.

• Non breaking changes
  Platform evolution prioritises backwards compatibility. Extensions to the API are additive, preserving existing behaviour while introducing new capabilities. This enables continuous platform improvement without disrupting existing integrations. We deploy multiple deployments a day in this fashion, continually enhancing your product experience and capabilities
• Feature flags
  New functionality is controlled through firm-level feature flags, enabling controlled rollout and validation of changes. This mechanism provides a six month window for firms to adopt new behaviours before being sunset, balancing innovation with stability. Firms can work with the account team to manage their adoption timeline within this window
• Breaking changes
  When a material change is required that can't be introduced through extension, it's implemented as a new and distinct API path. This provides clear separation between old and new behaviours. A six month migration period allows firms to transition at their own pace, with both old and new paths maintained during this window. This approach supports significant platform evolution while providing stability and predictability for integrating firms

Error responses are designed with standardisation in mind. This approach aims to provide machine-readable yet human-friendly error responses, enabling both automated processing and efficient debugging. The error handling design delivers actionable and contextual errors, including problem type identification, clear descriptions, and request traceability through unique identifiers.

The platform is built to enterprise standards with clear service level commitments, ensuring reliable performance for business-critical operations. These service levels encompass availability, response time, and recovery objectives.

• Availability
  The infrastructure operates across three availability zones in an active-active-active configuration, with a service level agreement of 99.9% and an internal service level objective of 99.99%. This architecture ensures robust service delivery for business-critical operations
• Performance
  The platform is engineered to deliver consistent sub-millisecond response times, with a 500ms target for 95th percentile API responses. This level of performance enables real-time operations and supports high-frequency trading capabilities, where required. To bring confidence to this we regularly load test our platform to 300% of current peak volumes, giving us foresight of any potential problems