New in Basecamp 3: Webhooks

We recently launched a full API for Basecamp 3. That’s great for when you want to programmatically retrieve or post content. But what if you just want your program to be told when there’s something changes? Well, that required polling at regular intervals. Bah!

With our newly launched webhooks, you can instead have Basecamp call your program when things you care about change. Let’s say you want to resend all messages in the company-wide basecamp onto a mailing list. Just register a webhook about the “message” content type, and Basecamp will call a URL of your choice with all the details about the new message.

This new feature also allows integrators like Zapier to make more efficient, faster links between other apps. So even if you don’t write your own programs, you stand to benefit.

How to setup a new webhook

You can programmatically register new webhooks through the webhooks API. That’s great when you have a full Basecamp 3 integration that is already authenticated with OAuth. Then you can just add the webhooks you need automatically.

But you can also setup webhooks via the web UI:

Step 1: Select “Set up webhooks for this Basecamp”

Step 2: Click “Add a new webhook” — this is also where you’ll see existing webhooks added

Step 3: Enter the HTTPS payload URL we should call and select the content types you want to hear about.

Step 4: When the content type you’ve asked to hear about changes in the Basecamp, you can click on the webhook from the index to see the latest deliveries. Complete with request/response logs for debugging.

Happy integrating!

Announcing the Basecamp 3 API

Basecamp 3 finally has an API! Head to https://github.com/basecamp/bc3-api for documentation and a guide to getting started.

We’re already seeing some great 3rd party integrations like Tick’s time tracking service and expect many more to come soon. If you have an integration you’d like us to know about, be sure to submit it here.

Some technical details:

  • The API is all part of the same majestic monolith that powers the web interface. Same controllers, new Jbuilder views.
  • Everything is cached to the max with liberal use of Russian Doll caching and ETags. While layering it on, I found and fixed a few related issues so consider the campsite cleaner than I found it!
  • Pagination is implemented following RFC5988’s convention of `Link` headers to provide URLs for the `next` page.
  • In-app Rate limiting is handled by Jeremy’s excellent Rack::Ratelimit middleware.
  • Traffic is served on a separate domain to help shield from CSRF and session vulnerabilities, and to aid with monitoring, routing, and throttling.

That’s all. Happy APIing!