Welcome to the Basecamp 4 API! If you're looking to integrate your application with Basecamp 4 or create your own application in concert with data inside of Basecamp 4, you're in the right place. We're happy to have you!
The Basecamp 4 API is not compatible with the Basecamp Classic API or the Basecamp 2 API. All integrations will start fresh with the new API. The core ingredients are the same, though: Basecamp 4 is a REST-style API that uses JSON for serialization and OAuth 2.0 for authentication.
If you've used a previous version of the Basecamp API, you need to adapt your integration code. Here are some notable changes for the Basecamp 4 API:
- We require OAuth 2.0 for authentication—no more Basic authentication
- Pagination is performed via the
LinkandX-Total-Countheaders
All URLs start with https://3.basecampapi.com/999999999/. URLs are HTTPS only. The path is prefixed with the account ID, but no /api/v1 API prefix. Also, note the different domain!
To make a request for all the projects on your account, append the projects index path to the base URL to form something like https://3.basecampapi.com/999999999/projects.json. In cURL, it looks like this:
curl -H "Authorization: Bearer $ACCESS_TOKEN" -A 'MyApp (yourname@example.com)' https://3.basecampapi.com/999999999/projects.jsonTo create something, it's the same idea, but you also have to include the Content-Type header and the JSON data:
curl -H "Authorization: Bearer $ACCESS_TOKEN" \
-H 'Content-Type: application/json' \
-A 'User-Agent: MyApp (yourname@example.com)' \
-d '{ "name": "My new project!" }' \
https://3.basecampapi.com/999999999/projects.jsonThroughout the Basecamp 4 API docs, we include "Copy as cURL" examples. To try the examples in your shell, copy your OAuth 2.0 access token into your clipboard and run:
export ACCESS_TOKEN=PASTE_ACCESS_TOKEN_HERE
export ACCOUNT_ID=999999999Then you should be able to copy/paste any example from the docs. After pasting a cURL example, you can pipe it to a JSON pretty printer to make it more readable. Try jsonpp or json_pp on OSX:
curl -s -H "Authorization: Bearer $ACCESS_TOKEN" https://3.basecampapi.com/999999999/projects.json | json_ppAs mentioned above, to authenticate you must use OAuth 2.0. OAuth 2.0 allows users to authorize your application to use Basecamp on their behalf without having to copy/paste API tokens or touch sensitive login information.
Read the authentication guide to get started.
You must include a User-Agent header with both:
- The name of your application
- A link to your application or your email address
We use this information to get in touch if you're doing something wrong (so we can warn you before you're blacklisted) or something awesome (so we can congratulate you). Here are examples of acceptable User-Agent headers:
User-Agent: Freshbooks (http://freshbooks.com/contact.php)User-Agent: Fabian's Ingenious Integration (fabian@example.com)
If you don't include a User-Agent header, you'll get a 400 Bad Request response.
We use JSON for all API data. The style is no root element and snake_case for object keys. This means that you have to send the Content-Type header Content-Type: application/json; charset=utf-8 when you're POSTing or PUTing data into Basecamp. All API URLs end in .json to indicate that they return JSON. Alternatively you can send Accept: application/json.
You'll receive a 415 Unsupported Media Type response code if you don't include the Content-Type header.
Most collection APIs paginate their results. The number of requests that'll appear on each page is variable. In most cases, we use a geared pagination ratio with 15 results on page 1, 30 on page 2, 50 on 3, and then 100 on 4 and above. The Basecamp 4 API follows the RFC5988 convention of using the Link header to provide URLs for the next page. Follow this convention to retrieve the next page of data—please don't build the pagination URLs yourself!
Here's an example response header from requesting the third page of messages:
Link: <https://3.basecampapi.com/999999999/buckets/2085958496/messages.json?page=4>; rel="next"
If the Link header is blank, that's the last page. The Basecamp 4 API also provides the X-Total-Count header, which displays the total number of resources in the collection you are fetching.
You must use HTTP freshness headers to speed up your application and lighten the load on our servers. Most API responses will include an ETag or Last-Modified header. When you first request a resource, store these values. On subsequent requests, submit them back to us as If-None-Match and If-Modified-Since, respectively. If the resource hasn't changed since your last request, you'll get a 304 Not Modified response with no body, saving you the time and bandwidth of sending something you already have.
API clients must expect and gracefully handle transient server errors and rate limits. We recommend baking graceful 5xx and 429 retries into your integration from the beginning so errors are handled automatically.
We return a 429 Too Many Requests response when you've exceeded a rate limit. Consult the Retry-After response header to determine how long to wait (in seconds) before retrying the request.
Plan ahead to gracefully handle the failure modes that API backpressure will exert on your integration. Multiple rate limits are in effect, e.g. for GET vs POST requests and per-second/hour/day limits, and they're adjusted dynamically, so responding to them dynamically is essential, particularly at high traffic levels.
For a sense of scale, the first rate limit you'll commonly encounter is currently 50 requests per 10 second period per IP address.
If Basecamp is having trouble, you will get a response with a 5xx status code indicating a server error. 500 (Internal Server Error), 502 (Bad Gateway), 503 (Service Unavailable), and 504 (Gateway Timeout) may be retried with exponential backoff.
API requests may 404 due to deleted content, an inactive account, missing user permissions, etc. Detect these conditions to give your users a clear explanation about why they can't connect to Basecamp. Do not automatically retry these requests.
- Inactive account. 404 Not Found response with a
Reason: Account Inactiveheader. Due to an expired trial or account suspension. All API requests to an inactive account will fail, so we recommend detecting and disabling the account in your integration as well. - Inaccessible items. 404 Not Found response. Due to a deleted item or insufficient permissions.
Many resources, including messages, documents, and comments, represent their content as rich text in HTML. Rich text content may contain lists, block quotes, simple formatting, and inline attachments such as mentions, images, and files.
See the Rich text section for more information about working with HTML and attachments in rich text content.
- Attachments
- Campfires
- Card table cards
- Card table columns
- Card table steps
- Card tables
- Chatbots
- Client approvals
- Client correspondences
- Client replies
- Client visibility
- Comments
- Documents
- Events
- Forwards
- Inbox replies
- Inboxes
- Lineup Markers
- Message Boards
- Message Types
- Messages
- People
- Projects
- Question answers
- Questionnaires
- Questions
- Recordings
- Schedule entries
- Schedules
- Subscriptions
- Templates
- To-do list groups
- To-do lists
- To-do sets
- To-dos
- Uploads
- Vaults
- Webhooks
To add your application to our public list of Basecamp 4 integrations, go to https://github.com/basecamp/bc3-integrations and open a pull request.
If you have a question about the API, please open a support ticket.
Please note that this project is released with a Contributor Code of Conduct. By participating in discussions about the Basecamp 4 API, you agree to abide by these terms.
These API docs are licensed under Creative Commons (CC BY-SA 4.0). Please share, remix, and distribute as you see fit.
