Resources #

Alpaca Learn #

We post regular content on our Alpaca Learn resource site where you can find the latest market updates, development tools and tips and much more to help you along your journey developing with Alpaca.

Blog #

Dont miss a beat and find the latest updates from Alpaca in our blog.

Slack Community #

We have an active community on Slack with developers and traders from all over the world. For Broker API we have a dedicated channel #broker-api for you to discuss with the rest of the community building new products using Broker API. You will be automatically added to #announcements, #community, #feedback, and #q-and-a.

Forum #

We have set up a community forum to discuss topics ranging from integration, programming, API questions, market data, etc. The forum is also a place to find up-to-date announcements about Alpaca and its features. The forum is the recommended place for discussion, since it has more advanced indexing and search functionality compared to our other community channels.

Support #

Have questions? Need help? Check out our support page for FAQs and to get in contact with our team.

Systems Status #

Stay up to date with Alpaca services status and any updates on outages.

Disclosures #

See disclosures.


API Reference #

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 in order to help make sure that as a developer you know what to expect, when to expect, and how to properly handle certain scenarios .

Backwards Compatible Changes #

You should expect any of the following kind 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 status to a set of all possiv`)
  • Enhancing ordering on how certain lists get returned
  • Supporting new HTTP versions (HTTP2, QUIC)
  • Adding new HTTP method(s) for an existing endpoint
  • Expecting new HTTP request headers (eg. new authentication)
  • Sending new HTTP headers (eg. HTTP caching headers, gzip encoding, etc.)
  • Increasing HTTP limits (eg. Nginx large-client-header-buffers)
  • Increasing rate limits
  • Supporting additional SSL/TLS versions

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. IE 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

Unexpected breaking changes

We strive to avoid breaking changes without upfront planning and communication, however these can slip through in exceptional circumstances.

In the event a change occurs and you consider it a breaking change please reach out to [email protected] and we will do our best to work with you through the change.

Edit Edit this page