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
Link
andX-Total-Count
headers
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 ([email protected])' https://3.basecampapi.com/999999999/projects.json
To 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 ([email protected])' \
-d '{ "name": "My new project!" }' \
https://3.basecampapi.com/999999999/projects.json
Throughout 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=999999999
Then 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_pp
As 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 ([email protected])
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 Inactive
header. 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.