Start with what the platform already does
Outcomes
What decides whether a system can be connected
Whether a client's software can be connected is decided by that software, not by the platform. A system that publishes an API can be reached. A system that does not publish one cannot, no matter what you build on this side.
That makes the first question of every integration a one-minute question: does this system have an API? The answer is usually on its own website, under a heading called API or Developers. Find that page and you know whether the conversation is about how, or about whether.
The ladder from a setting to custom code
Once you know a system can be reached, the second question is how far you have to go. There is a ladder here, and the rung that does the job is almost never the one you reach for first.
- A setting that already exists. Many jobs are a field, a toggle, or a native integration nobody told you about. Check before you build.
- An automation. If the whole job happens inside the platform, a trigger and a few steps finish it, with nothing external involved.
- A glue tool. Zapier or Make connects two systems without code. Good for one client and one flow; the cost climbs as you repeat it, and the platform meets it with a
Triggered via Zapierautomation trigger. - A custom tool. An AI Employee reaching a system directly, mid-conversation, using judgment about when to reach.
- The API. Your own code working with platform records on a schedule or in bulk.
- Custom code. Reshaping or reconciling data that does not line up. This is developer work, and it has its own handoff.
Every step in this path names the rung it is on. Reaching for the lightest one that does the job is the whole skill, and it is what keeps a build maintainable a year later.
Prove the built-in half first
You are here: Business App, inside your test account. The build in this path lives here until the API step.
The build this path carries is an AI Employee for a home-services client: it books jobs on a real calendar and saves every lead to the CRM. Both of those are rung one. Before adding anything custom, confirm the platform's own half works, because a custom piece added to an unproven build gives you two things to debug at once.
Labwatch it book and capture, untouched
Go to your AI Employee's Chat.
Keep that contact. It is the same record you will read back through the API at the end of this path, which is how you will know the two halves are the same system.
The one job left over
Gutter cleaning happens outside, and a booking made into a storm helps nobody. The platform does not know this client cares about weather, and no setting, automation, or glue tool supplies that judgment inside the conversation itself. That is rung four, and it is the only rung this build needs.
Naming the leftover job precisely is what keeps a build small. Not "make it smarter" and not "connect it to everything": one sentence about one moment. For this build it is that the employee checks the forecast before it confirms outdoor work, and offers a clear day instead when the forecast is bad.
Open Conversations, find the chat you just had, and click Explanation under the booking message. You are meeting the view while everything works, which is the only time it is easy to read.
Knowledge Check
Three quick questions on what makes a system connectable, choosing a rung, and what the platform already covers.