When you're ready to integrate the power of the .do agentic workflow platform into your application, you have a fundamental choice: make direct HTTP calls to our REST API or use one of our official Software Development Kits (SDKs).
While direct API calls offer a raw, dependency-free approach, we’re here to show you why leveraging the .do SDK is almost always the superior choice. It's not just about convenience; it's a strategic decision that accelerates development, enhances reliability, and future-proofs your codebase.
Let's break down the difference and explore why our SDKs are the recommended path for building robust, scalable integrations.
We get it. As a developer, you value control and simplicity. Hitting an API endpoint directly with curl or a built-in HTTP client like fetch can seem appealing for a few reasons:
This approach is fine for a quick test or a one-off script. But for building a real application, the initial simplicity quickly gives way to complexity and long-term maintenance headaches.
Our SDKs are more than just thin wrappers around our API. They are thoughtfully designed developer tools that handle the heavy lifting of API integration, so you can focus on your application's core logic.
The most immediate benefit is how much cleaner and more concise your code becomes. The SDK abstracts away the boilerplate of HTTP requests, authentication, and endpoint routing.
Consider this example of running a workflow.
Before: Direct API Call with fetch
Look at all the manual work: setting headers, stringifying the body, checking the response status, and parsing the JSON.
// Direct API Call with fetch
async function runCustomerOnboardingWithApi(customerData: any) {
const DO_API_KEY = process.env.DO_API_KEY;
const API_ENDPOINT = 'https://api.do-platform.com/v1/workflows/run';
try {
const response = await fetch(API_ENDPOINT, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': `Bearer ${DO_API_KEY}`,
},
body: JSON.stringify({
name: 'customer-onboarding-workflow',
input: { customer: customerData },
}),
});
if (!response.ok) {
// Manually handle different error statuses...
throw new Error(`API call failed with status: ${response.status}`);
}
const result = await response.json();
console.log('Workflow started:', result.runId);
return result;
} catch (error) {
console.error('Failed to run workflow:', error);
}
}
After: Using the .do TypeScript SDK
The SDK handles all the underlying complexity. Your code is cleaner, more readable, and focused on the task at hand.
// With the .do SDK
import { Do } from '@do-platform/sdk';
const doClient = new Do({
apiKey: process.env.DO_API_KEY,
});
async function runCustomerOnboarding(customerData: any) {
try {
const result = await doClient.workflows.run({
name: 'customer-onboarding-workflow',
input: { customer: customerData },
});
console.log('Workflow started:', result.runId);
return result;
} catch (error) {
console.error('Failed to run workflow:', error);
}
}
This simplicity is by design, letting you access the full power of our agentic workflow platform in your native language.
For languages like TypeScript, our SDKs are a game-changer. They come fully typed, which means:
This type-safe environment drastically reduces runtime bugs and significantly improves the developer experience.
A robust API integration is more than just sending a request. It's about handling the realities of network communication. Our SDKs come with critical best practices baked in:
APIs evolve. New features are added, and occasionally, breaking changes are necessary.
While the SDK is the best choice for 99% of use cases, there are a few niche scenarios where a direct call might be appropriate:
For any real application development, these exceptions prove the rule: the SDK is the clear winner.
Choosing the .do SDK over direct API calls isn't just a matter of preference—it's a strategic move to build better software, faster. You gain simplicity, safety, and maintainability, allowing you to focus on creating innovative solutions with our agentic workflow platform.
Ready to build with ease?