APIs That Other Developers Want to Use
B2B platforms live and die by their APIs. If your partners hate integrating with you, they’ll find someone else. I design API surfaces in Laravel that are consistent, well-documented, and built for the developer on the other end. Whether that’s a separate Vue 3 frontend consuming your data, a mobile app, or a third-party partner building against your endpoints.
On Dadooo.ai, the API serves a standalone Vue 3 SPA, handles OAuth integrations with Meta, Google, and Microsoft, processes webhook callbacks from Stripe, and manages real-time WebSocket connections. Every endpoint follows the same patterns: consistent error responses, versioned paths, token authentication, and rate limiting. A new developer joining the project can look at any endpoint and immediately know the conventions.
On Exlink, the API is the product. Partners in real estate integrate with it to push and pull property listings, manage availability, and sync pricing. If the API goes down or behaves inconsistently, their business stops. That constraint shaped every decision.
How I Design APIs
Contracts First
Before writing implementation code, I define the contracts. Request schemas, response shapes, error codes, and pagination patterns. These become the OpenAPI specification that generates interactive documentation. The frontend team can start building against mocked endpoints while I implement the real logic behind them.
This isn’t waterfall. The contracts evolve during development. But starting with them means the frontend and backend don’t block each other, and partners get documentation that matches reality.
Versioning and Backwards Compatibility
Breaking changes are expensive when other teams build against your API. I version endpoints at the URL level (/api/v1/, /api/v2/) and maintain backwards compatibility within a version. When a breaking change is necessary, the old version stays available with a deprecation timeline.
Authentication and Authorization
Sanctum for first-party SPAs (cookie-based, CSRF-protected). Token-based auth for third-party integrations with scoped permissions. OAuth when partners need it. Rate limiting per token, per IP, and per tenant. Every platform gets the auth layer that matches its access patterns.
Error Handling
Consistent error responses across every endpoint. Machine-readable error codes, human-readable messages, field-level validation errors for form submissions. When something goes wrong, the consuming developer gets enough information to fix it without calling me.
Integration Layer
Most enterprise platforms need to talk to other systems. Payment processors, CRMs, ERPs, social media APIs, notification services. I’ve integrated with Stripe, Meta (Facebook + Instagram), Google (Calendar + OAuth), Microsoft (Outlook + OAuth), ElevenLabs, OpenRouter, Runware, and dozens more.
How I Structure Integrations
Each third-party service lives behind a clean interface in the codebase. The application talks to the interface, not the vendor’s SDK directly. This means:
- Swapping providers doesn’t ripple through your domain logic. When Dadooo.ai needed to switch from direct OpenAI calls to OpenRouter for multi-model support, the AI domain service stayed untouched. Only the adapter changed.
- Testing works against the interface with fakes, not against live APIs that rate-limit you in CI.
- Failure isolation: if Stripe is down, the billing integration retries gracefully. The rest of the platform keeps running.
Webhook Systems
I build webhook receivers and senders. On the receiving end: signature verification, idempotency keys, and async processing so the webhook caller gets a fast 200 response while actual processing happens in a queue. On the sending end: delivery tracking, automatic retries with exponential backoff, and a dashboard showing delivery status per event.
On Exlink, webhooks notify partners of listing updates in real-time. Delivery failures get retried up to 5 times over 24 hours, with alerts if a partner’s endpoint is consistently down.
What Ships
- REST API with OpenAPI spec, versioning, rate limiting, and consistent error handling
- Interactive documentation generated from the spec, so it never drifts from reality
- Token management with scoped permissions, rotation support, and usage analytics
- Webhook infrastructure with delivery tracking, retry logic, and signature verification
- Integration adapters isolated behind interfaces with proper error boundaries
- Monitoring: New Relic for API latency tracking, alerting on error rate spikes, and slow endpoint detection
Who Needs This
You’re building a platform where the API is a product surface. Partners integrate with you. Frontend teams consume your endpoints. Mobile apps depend on your data. The API can’t be an afterthought bolted on after the platform is built.
If your business depends on other developers successfully integrating with your system, the API design matters.
Frequently Asked Questions
REST or GraphQL?
REST. For the B2B platforms I build, REST with OpenAPI documentation is the right choice. Partners understand it immediately, tooling is mature, caching works at the HTTP level, and debugging is straightforward. GraphQL solves problems that most B2B APIs don’t have (deeply nested data with variable shapes requested by many different clients). If you have a specific case where GraphQL genuinely fits better, I’ll tell you. But I won’t use it just because it’s trendy.
How do you handle API versioning?
URL-level versioning (/api/v1/, /api/v2/). It’s explicit, easy to route, and partners always know which version they’re hitting. Within a version, I maintain backwards compatibility strictly. Adding fields is fine. Removing or renaming fields is a breaking change that goes into the next version with a deprecation timeline for the old one.
What about rate limiting for third-party partners?
Every API I build includes rate limiting at multiple levels: per token, per IP, and per tenant. Limits are configurable per partner based on their plan or agreement. Response headers always include remaining quota and reset time. When a partner hits the limit, they get a clear 429 response with enough information to back off gracefully instead of guessing.
Can you integrate with APIs that have terrible documentation?
Yes, and most do. I’ve integrated with payment processors, CRMs, social media platforms, and government systems. The approach is the same: isolate the mess behind a clean adapter interface so your application never touches the vendor’s quirks directly. When the vendor changes something (and they will), you update one adapter, not fifty call sites.
How long does it take to build a public API?
A well-designed REST API with authentication, rate limiting, versioning, and OpenAPI documentation typically takes 2-4 weeks for the foundation depending on the number of resources. After that, each new endpoint follows established patterns and ships in hours, not days. The upfront investment in consistent conventions pays off immediately.