Why API?

Alpaca’s features to access financial markets are provided primarily via API. We believe APIs are the essential means to interact with brokerage services and innovate your business. Our API is designed to fit your needs, enabling partners to embed investing directly into their platforms.

REST, SSE and Websockets

Our API is primarily built in the REST style, providing a simple and powerful way to integrate with our services.

In addition to the REST API which replies via synchronous communication, our API includes an asynchronous event API which is based on Server-Sent Events (SSE). As many types of events occur in the financial markets (orders fill based on market movement, cash settles after transfers, etc.), this event-based API helps you get updates instantly and provide the best user experiences to your customers.

Architecture

To comply with the European General Data Protection Regulation (GDPR), the Spanish Organic Law 3/2018 (LOPDGDD), and the rules of the Comisión Nacional del Mercado de Valores (CNMV) under the MiFID II framework, Alpaca Europe utilizes a secure "Two-Ledger" dual-cluster architecture.

The Alpaca Europe platform is hosted locally on a dedicated European cluster within the Google Cloud Platform (GCP). This dedicated European cluster houses our core European API gateway, the Europe Identity Service, and the Europe Ledger, which acts as the official book of record and secure vault for all European Personally Identifiable Information (PII).

When a European client places a trade for a US-listed security, the European cluster performs real-time validation and sends a secure, anonymized API call (containing zero PII) across the border to our US infrastructure. The US Order Management System (OMS) then routes the trade for execution and clearing via non-disclosed Omnibus sub-accounts. This ensures that your clients get access to low-latency US market execution while their sensitive data never leaves Europe.

API Updates & Upgrades

In an effort to continuously provide value to our developers, Alpaca frequently performs updates and upgrades to our API. We’ve added the following sections to our docs to help make sure that as a developer you know what to expect, when to expect it, and how to properly handle certain scenarios.

Backwards Compatible Changes

You should expect any of the following kinds of changes that we make to our API to be considered a backwards compatible change:

• Adding new or similarly named APIs.
• Adding new fields to already defined models and objects such as API return objects, nested objects, etc. (Example: adding a new code field to error payloads).
• Adding new items to defined sets or enumerations such as statuses, supported assets, etc. (Example: adding new account statuses).
• Enhancing ordering on how certain lists get returned.

Generally, as a rule of thumb, any append or addition operation is considered a backwards compatible update and does not need an upfront communication. These updates should be backwards compatible with existing interfaces and not cause any disruption to any clients calling our APIs.

Breaking Changes

When and if Alpaca decides to perform breaking changes to our APIs the following should be expected:

• Upfront communication with sufficient time to allow developers to be able to react to new upcoming changes
• Our APIs are versioned, if breaking changes are intended we will generally bump the API version. For example, a route might go from being /v1/accounts/{account_id} to /v2/accounts/{account_id} if we had to make a breaking change to either the parameters it can take or its return structure