February API updates

Localization

Coinbase products are available in a growing number of languages. To support our international expansion efforts, we’re making it easier for our API partners to support their users in their native languages. You can now get localized error messages and other strings in alternative languages by passing in the Accept-Language header as part of your API request. Available languages are listed in our API reference.

CORS support

By default, browsers restrict AJAX requests to domains other than the current one. This is a security measure that’s in place to prevent malicious intent. APIs and other sites can alternatively whitelist this browser access using cross-origin resource sharing, more commonly known as CORS. To enable more interesting use cases for Coinbase’s API, we enabled CORS for both the Coinbase Wallet API and the Coinbase Exchange API.

Transaction details

Coinbase supports a multitude of different transaction ledger types. A couple of the most common ones are send for sending bitcoin and buy for buying bitcoin. At the time of this announcement, we’re supporting 11 different types and will likely add more in the future.

{
  "id": "57ffb4ae-0c59-5430-bcd3-3f98f797a66c",
  "type": "send",
  "status": "completed",
  "amount": {
    "amount": "-0.00100000",
    "currency": "BTC"
  },
  ...
  "details": {
    "title": "Sent bitcoin",
    "subtitle": "to User 2"
  }
}

This means that constructing a readable transaction list for a wallet hasn’t been easy given the sheer amount of different types and their variations. To simplify this, we added more detailed information to transaction resource. They’ll now include a details hash which contains title and subtitle values which can be used to contruct human readable transaction entries. These values also respect localization and will be translated based on the Accept-Language header.

Changes to API versioning

We recently added notifications to the Coinbase API. As notifications are delivered via POST requests (webhooks), they can’t be versioned using our existing versioning schema where one needs to pass the date of the implementation as the CB-Version header.

Given that we would have needed to make a breaking change to the notification resource payload, we decided to add a user level API version designation which can be controlled from API settings. For both notification and API requests where the user hasn’t defined their API version within the header, this default version will be used. For requests, using the CB-Version header is still the recommended way to define your version, as also used in our client libraries.

New endpoint: historic bitcoin prices

We added an easy way to get historic bitcoin prices used by Coinbase. The new endpoint doesn’t require authentication and is available at GET api.coinbase.com/v2/prices/historic. You can also get the value using our client libraries.

Upgrading from legacy API v1 to v2

To make it easier for users of our legacy API v1 to upgrade to the newer API v2, we have added new fields to v1 responses. Given that we started using UUID as resource identifier in the new v2, it hasn’t been easy to map existing objects from v1 to v2. To solve this we added a new uuid field to v1 resources, which maps to v2 resource ids.

To see all recent API changes, visit our API changelog.

Please note: We’re hiring engineers (both in our San Francisco office and remote anywhere in the world). If you’re interested in speaking with us about a role we’ve set up a coding challenge that you can take in about 30–45 minutes. You can also apply through our careers site if you prefer to start the conversation that way.

Written by Jori Lallo