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.
Understanding Basecamp's domain model helps you navigate the API effectively.
Every project has exactly one bucket—its storage container for all content. In API URLs, bucket_id and project ID are the same value:
/buckets/12345/todolists/67890.json
↑
This is the project ID
When you see /buckets/{id}/... in the API, think "project." (Templates also have buckets internally, but they use /templates/... endpoints.)
A recording is an entry in a bucket. Every piece of content—to-dos, messages, documents, comments, uploads, schedule entries, and 50+ other types—has a recording that tracks:
- Status:
active,archived,trashed(publication state, separate from completion) - Tree structure: parent/child relationships for nesting
- Visibility: whether clients can see the content
- Subscriptions: who gets notified of changes
The recordings endpoint queries across projects by type (required): ?type=Todo, ?type=Message, etc.
Each project has a dock—a list of available tools. Check the dock to discover what's enabled:
"dock": [
{ "name": "message_board", "enabled": true, "url": "...", "id": 123 },
{ "name": "todoset", "enabled": true, "url": "...", "id": 456 },
{ "name": "schedule", "enabled": false, "url": "...", "id": 789 }
]The dock is your source of truth for available tools. Common ones: message_board, todoset, vault (files), schedule, chat (campfire), questionnaire (automatic check-ins), inbox (email forwards), kanban_board (card table).
Always check enabled: true before using a tool—not all projects have all tools turned on.
To-dos have a specific container structure:
Project
└── To-do set (exactly one per project, find via dock)
├── To-do list "Launch tasks"
│ ├── To-do item
│ └── To-do item
└── To-do list "Research"
└── To-do item
To create a to-do list, POST to the to-do set, not the project:
POST /buckets/{project_id}/todosets/{todoset_id}/todolists.json
The to-do set pattern repeats for other tools. Each is a singleton container accessed via the dock:
| Tool | Container | Contains |
|---|---|---|
| Message board | One per project | Messages |
| Vault | One per project | Documents, uploads, folders |
| Schedule | One per project | Schedule entries |
| Questionnaire | One per project | Questions (check-ins) |
| Card table | One per project | Columns → Cards |
Content items have a parent object showing their container:
{
"id": 67890,
"type": "Todo",
"parent": {
"id": 11111,
"type": "Todolist",
"title": "Launch tasks",
"url": "..."
}
}Use parent for navigation. A to-do's parent is its to-do list. A message's parent is the message board.
The resource is called person (not user). Endpoints:
/people.json— list people in account/people/{id}.json— single person/projects/{id}/people.json— people in a project/my/profile.json— current authenticated user
Completion: To-dos have a boolean completed field. By default, endpoints return active, pending (not completed) items. Use ?completed=true for completed items. Use ?status=archived or ?status=trashed to see those.
Assignees: Always an array, even for single assignment. When creating: "assignee_ids": [123].
Don't confuse recording status with to-do completion:
- Status (
active,archived,trashed): Publication state. Applies to all recordings. - Completed (
true/false): Whether a to-do is done. Only applies to to-dos, cards, and card steps.
A to-do can be completed: true and status: "active" (done but not archived).
- 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
- Search
- Subscriptions
- Templates
- Timesheets
- 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.