Related
Recommended
Eli Torres (Staff)

Hey everyone — wanted to share where our heads are at with integrations this year, since I've been getting a lot of DMs and questions in the dev Slack about what's changing.

The short version: we're being more intentional. The longer version: well, keep reading.

From "build anything" to "build what matters"

Last year we shipped 14 new integrations. Some of them — QuickBooks Online, the Salesforce connector — are getting heavy use. Others... honestly, I forget they exist until someone pings me about a bug. That's not great for anyone.

So in 2025 we're moving to a partner-tier model. Three buckets:

  • Tier 1: Native integrations — We build and maintain these. Deep feature parity, dedicated QA, docs that I actually review. Think QuickBooks, Salesforce, and the upcoming ServiceTitan migration tool (more on that soon).
  • Tier 2: Verified partners — Built by third parties, but we've done code review, security audit, and committed to API stability. These get a badge in our marketplace and first access to new webhook events.
  • Tier 3: Community integrations — Everything else. Still valid, still supported via our public API, but you're working with the standard rate limits and we can't guarantee backwards compatibility on beta endpoints.

What this means if you're building on our API

If you're maintaining an integration — or planning one — the path to Tier 2 is basically:

  1. Use API v2.1 or later. v1 is entering maintenance mode and honestly, yeah, this one tripped me up too when I first looked at it. The pagination alone...
  2. Implement webhook verification properly. We're starting to reject apps that don't validate signatures. (API v2.1 webhook improvements make this way easier, btw.)
  3. Handle rate limits gracefully. 429 responses include a Retry-After header — use it. We've seen too many integrations that just hammer the endpoint until they get banned.

There's a full checklist in the partner portal. If you don't have access yet, email me directly.

The integrations we're actively seeking

Not gonna lie, we also have a shopping list. If you're at a company in these spaces — or you know someone — we want to talk:

  • Fleet/telematics (GPS + vehicle diagnostics)
  • Specialty equipment rental platforms
  • Commercial HVAC supply chain management
  • State-level licensing and compliance databases

The goal is fewer, deeper integrations rather than surface-level connections to everything. I'd rather have one partner that lets us sync parts inventory in real-time than five that just push basic contact records.

A note on breaking changes

With the tier system comes a real commitment: Tier 1 and Tier 2 integrations get 12 months notice on any breaking API changes. We're documenting this in a public RFC process starting next month. No more finding out about deprecated endpoints from a changelog entry buried three pages deep.

That's the gist. Happy to answer questions in the comments — especially if you're hitting edge cases with the current webhook event payloads. I know the job.updated event in particular has some... quirks.

  • in reply to Omar Hassan

    Good questions — draft RFC currently defines "breaking" as any change that would cause a correctly-implemented client (i.e., one following our documented contract) to fail. So:

    • Field removal: Yes, breaking. We're committing to additive-only.
    • Enum extension: Gray area. If your client does strict validation, new values break you. We're leaning toward treating this as breaking and providing 12 months notice, plus a X-API-Deprecated-Values header or similar during the transition.
    • Webhook semantics: Ordering changes would be breaking; retry count changes probably not (within reason). This one needs more internal discussion.

    RFC 7807 adoption is on the table — we're currently using a custom error shape that's... not great. Will update the draft if we commit to the spec.

  • From a governance perspective, the 12-month deprecation commitment is welcome. However, it is worth noting that the phrase "breaking API changes" requires precise definition. Does this include:

    • Removal of fields from response payloads (i.e., additive-only guarantees)?
    • Changes to enum value sets (e.g., job.status gaining new states)?
    • Modifications to webhook delivery ordering or retry semantics?

    The RFC should reference specific sections of the RFC 7807 problem details specification if you're adopting standard error formats, which would assist in automated client adaptation.

  • in reply to Carlos Vega

    Yeah this is one of those edge cases I mentioned — it's only returned when you're within 20% of your limit. Which is... not documented well. Here's the actual behavior:

    // Always present
X-RateLimit-Limit: 1000

// Only when remaining < 200
X-RateLimit-Remaining: 189
X-RateLimit-Reset: 1741264800

    We're fixing this in v2.2 to return it on every response. RFC should be up next week.

  • Can you share the current rate limit headers? Last I checked X-RateLimit-Remaining wasn't consistently returned on 200s.

  • in reply to Devon Marsh

    Ah yeah, that login flow is... not great. I'll flag it.

    On the migration tool — we're in closed beta with three customers right now. Shooting for public beta in May. If your client needs in earlier, email me their tenant size and I can check if they fit the current cohort.