Working with External Services
Modern SaaS applications are assembled from external services: Stripe for payments, S3 for file storage, SendGrid for email, Auth0 or Clerk for authentication, Sentry for error monitoring. Every one of these integrations has failure modes, edge cases, and security considerations that the happy path in the documentation doesn't cover. This module gives you a realistic, production-oriented introduction to integrating the services that power real applications. The risk with external service integrations is that they look simple in tutorials and reveal their complexity in production. A Stripe integration that handles basic payment intents is straightforward. A Stripe integration that correctly handles webhooks — with HMAC signature verification, idempotency, and retry logic — is engineering. An S3 integration that handles pre-signed URL expiry, handles upload failures, and correctly sets access policies is engineering. This module covers the production reality, not the tutorial path. You'll also spend time on the build vs. buy decision — the framework for evaluating when to integrate an external service versus building the capability in-house. Vendor lock-in is a real constraint, but so is the engineering cost of building and maintaining authentication, payment processing, or search yourself. Understanding this decision framework is what makes you a thoughtful architect rather than a reflexive adopter of every new SaaS tool.
What You'll Learn
-
1
The Anatomy of a Third-Party Integration — API keys, SDKs, webhooks, rate limits, idempotency
-
2
Payment Processing with Stripe — Payment intents, subscriptions, webhooks, and test mode
-
3
File Storage with AWS S3 — Buckets, pre-signed URLs, multipart uploads, lifecycle policies
-
4
Email with Transactional Services — Resend/SendGrid, deliverability, templates, bounces
-
5
Authentication Providers — Auth0, Clerk, OAuth 2.0 + OIDC, JWTs, and vendor lock-in
-
6
Search, Monitoring, and Analytics Services — Algolia, Sentry, and event tracking
-
7
Evaluating Third-Party Services — Build vs buy, vendor lock-in, exit strategy
Capstone Project: Build a SaaS Application with Four External Service Integrations
Build a complete SaaS application — subscription-based, with file attachments — integrating Stripe for subscription billing with webhook handling, S3 for file storage with pre-signed uploads, an authentication provider for user management, and Resend for transactional email. Every integration must handle failure gracefully: failed payments should trigger dunning sequences, failed uploads should produce meaningful errors, and webhook delivery failures should be handled with idempotent retry logic.
Why This Matters for Your Career
The ability to integrate external services quickly and correctly is one of the most direct path to business value in modern software development. A developer who can spin up Stripe billing, S3 file storage, and email delivery in a day creates significantly more value than one who spends weeks building these capabilities from scratch — poorly. The ROI on integrating battle-tested services versus building equivalents is rarely close. However, external service integrations are also one of the most common sources of production incidents. Webhook delivery failures, API rate limits, service outages, authentication token expiry — all of these affect real applications and require thoughtful handling. Engineers who build integrations with idempotency, graceful degradation, and retry logic build applications that survive their dependencies being unreliable. Vendor lock-in is the hidden cost of external service adoption, and the engineers who evaluate it honestly make better long-term architectural decisions. An authentication provider that abstracts the protocol completely is harder to migrate away from than one that uses standard OAuth flows. Understanding these tradeoffs — and designing integrations with an exit strategy — is what separates thoughtful engineers from those who optimize only for the immediate build.