API & Integration Development

Why API-first?

Every modern application is an API consumer. Your React frontend calls APIs. Your mobile apps call APIs. Your partners call APIs. Third-party services call your APIs through webhooks.

The API is not a technical detail. It is the product. Companies like Stripe, Twilio, and Plaid are worth billions because of their APIs. Even if you are not building an API product, treating your API as a first-class citizen determines how fast you can iterate, integrate, and scale.

API-first means:

• Design the API contract before writing implementation code
• Frontend and backend teams work in parallel against the contract
• Third-party integrations are planned from the start, not bolted on later
• Documentation is generated from code, never outdated

See how this fits into your development workflow: Development as a Subscription Guide

REST API development

REST remains the standard for public APIs, third-party integrations, and service-to-service communication. We build REST APIs that are consistent, documented, and a pleasure to consume.

OpenAPI/Swagger documentation

Every REST API we build includes an OpenAPI 3.1 specification generated directly from TypeScript code. NestJS decorators produce the spec automatically — the documentation is always in sync with the implementation.

What you get:

• Interactive Swagger UI for testing endpoints
• Auto-generated client SDKs (TypeScript, Python, Go, Java)
• Request/response validation against the spec
• Versioned API documentation

REST best practices we follow

Practice	How we implement it
Consistent naming	Plural nouns (/users), kebab-case for multi-word (/order-items)
HTTP methods	GET reads, POST creates, PUT replaces, PATCH updates, DELETE removes
Status codes	200 success, 201 created, 400 bad input, 401 unauthorized, 404 not found, 429 rate limited
Pagination	Cursor-based for real-time data, offset-based for static lists
Filtering	Query parameters with consistent syntax (?status=active&sort=-createdAt)
Error format	{ error: { code, message, details } } — always the same shape
Versioning	URL path (/v1/) or header-based, depending on your use case
HATEOAS	Links to related resources where it adds value

Rate limiting and throttling

Every API needs protection against abuse. We implement rate limiting at multiple levels:

• Global rate limit: Maximum requests per minute per API key
• Endpoint-specific limits: Stricter limits on expensive operations (search, exports)
• User-based quotas: Different limits for different subscription tiers
• Sliding window algorithm: Fair distribution, no burst penalization
• Response headers: X-RateLimit-Remaining, X-RateLimit-Reset so clients can self-regulate

GraphQL API development

For applications where the frontend needs flexible data fetching, GraphQL eliminates the over-fetching and under-fetching problems that plague REST APIs.

Code-first GraphQL with NestJS

We build GraphQL APIs using the code-first approach with NestJS resolvers. TypeScript decorators define the schema, Prisma provides type-safe database access, and the GraphQL schema is generated automatically.

Benefits of code-first:

• No SDL files to maintain separately from the code
• TypeScript types and GraphQL types are always in sync
• Refactoring tools work across the entire codebase
• IDE support for auto-complete and type checking

GraphQL features we implement

• Queries and mutations with input validation (Zod or class-validator)
• Subscriptions for real-time updates via WebSocket
• DataLoader for N+1 query prevention (automatic batching)
• Field-level authorization (different users see different fields)
• Pagination with Relay-style cursor connections
• File uploads with multipart request support
• Persisted queries for production security (block arbitrary queries)
• Query complexity analysis to prevent expensive queries from overwhelming the server

REST vs GraphQL decision matrix

Factor	Choose REST	Choose GraphQL
Consumers	External/third-party	Your own frontends
Data relationships	Simple, flat	Nested, graph-like
Caching needs	Critical (CDN)	Less important
API evolution	Versioned endpoints	Schema evolution
Team experience	REST is universal	Requires GraphQL knowledge
Real-time	Webhooks / SSE	Subscriptions (built-in)
Documentation	OpenAPI/Swagger	GraphQL Playground / introspection

For most SaaS products, we recommend GraphQL for your own clients and REST for external integrations. Your Node.js backend can serve both from the same NestJS application.

Authentication and authorization

Every API needs security. We implement authentication and authorization as reusable, tested modules that integrate with your existing identity provider or stand alone.

Authentication strategies

Strategy	Use case	Implementation
JWT (Bearer tokens)	SaaS applications, SPAs	Access + refresh token rotation
API keys	Third-party integrations, server-to-server	Hashed storage, scoped permissions
OAuth 2.0 / OIDC	Social login, enterprise SSO	Authorization code flow with PKCE
Session cookies	Traditional web apps, Next.js	HTTP-only, secure, SameSite
mTLS	Service-to-service in Kubernetes	Certificate-based mutual authentication

Authorization patterns

• RBAC (Role-Based Access Control): Admin, editor, viewer roles with permission matrices
• ABAC (Attribute-Based Access Control): Dynamic rules based on user attributes, resource ownership, and context
• Multi-tenancy: Tenant isolation at the database level (row-level security or schema-per-tenant)
• Field-level authorization: In GraphQL, different users see different fields on the same type

Security checklist

Every API we deliver passes this checklist:

• Input validation on every endpoint (Zod schemas)
• SQL injection prevention (Prisma parameterized queries)
• XSS prevention (output encoding, CSP headers)
• CORS configuration (explicit origins, no wildcards in production)
• Rate limiting on authentication endpoints (prevent brute force)
• Token rotation (short-lived access tokens, long-lived refresh tokens)
• Audit logging (who did what, when, from where)
• HTTPS only (HSTS headers, no HTTP fallback)

Payment integration with Stripe

Stripe is the payment platform we recommend for SaaS and e-commerce. We have integrated Stripe into dozens of projects, from simple one-time payments to complex marketplace billing.

What we implement

• Checkout Sessions: Hosted or embedded payment forms
• Subscriptions: Recurring billing with plan management, upgrades, downgrades, prorations
• Customer Portal: Self-service billing management (invoices, payment methods, cancellation)
• Webhooks: Event-driven processing for payment success, failure, subscription changes
• Connect: Marketplace payments with split billing and payouts to sellers
• Invoicing: Automated invoice generation and delivery
• Tax: Automatic tax calculation with Stripe Tax

Stripe webhook architecture

Webhooks are critical for payment reliability. We implement them with:

1. Signature verification: Every webhook is verified against Stripe's signing secret
2. Idempotency: Events are processed exactly once, even if Stripe retries
3. Event ordering: Handled through event timestamps, not delivery order
4. Error handling: Failed processing retries with exponential backoff
5. Monitoring: Alerts on webhook processing failures

Third-party integrations

Modern applications integrate with dozens of external services. We build integrations that are resilient, monitored, and maintainable.

Common integrations we build

Category	Services
Email	SendGrid, Postmark, AWS SES, Resend
Analytics	Segment, PostHog, Mixpanel, Google Analytics
Storage	AWS S3, Cloudflare R2, Google Cloud Storage
Search	Algolia, Meilisearch, Elasticsearch
Messaging	Twilio (SMS), Slack, Discord
CRM	HubSpot, Salesforce, Pipedrive
Auth	Auth0, Clerk, Supabase Auth
Monitoring	Sentry, Datadog, PagerDuty

Integration architecture

Every third-party integration follows the same pattern:

1. Adapter pattern: External service calls are wrapped in an adapter with a clean internal interface
2. Circuit breaker: If an external service is down, we fail gracefully instead of cascading failures
3. Retry with backoff: Transient errors are retried automatically with exponential backoff
4. Timeout management: Every external call has an explicit timeout
5. Fallback strategy: What happens when the service is unavailable? Queue for later, serve cached data, or degrade gracefully

This pattern means swapping one provider for another (e.g., SendGrid to Postmark) requires changing one adapter, not refactoring your entire application.

Webhooks: receiving and sending

Receiving webhooks

Third-party services send webhooks to notify you of events. We implement webhook receivers with:

• Signature verification: Every provider has a different signing mechanism. We verify every request.
• Idempotent processing: The same event delivered twice produces the same result
• Async processing: Webhook handlers acknowledge receipt immediately (200 OK) and process asynchronously through a job queue
• Dead letter queue: Failed processing is captured and retried, with alerting after repeated failures

Sending webhooks

When your API needs to notify external systems, we build a webhook delivery system:

• Event registration: Customers register webhook URLs and select events they want to receive
• Payload signing: HMAC-SHA256 signatures so recipients can verify authenticity
• Retry logic: Failed deliveries retry with exponential backoff (1s, 5s, 30s, 5m, 30m)
• Delivery logs: Customers can see what was sent, when, and whether it succeeded
• Rate limiting: Outbound webhooks are rate-limited to avoid overwhelming recipients

How we work on your API project

1. API design workshop

We define resources, endpoints, authentication strategy, and the event model. Output: an OpenAPI spec or GraphQL schema that both frontend and backend teams agree on.

2. Contract-first development

Frontend and backend develop in parallel against the agreed contract. Mock servers let the frontend team start immediately.

Learn more about our process: Development as a Subscription Guide

3. Implementation with testing

Every endpoint gets unit tests (service layer), integration tests (database + service), and E2E tests (full HTTP request/response cycle). Coverage target: 90%+.

4. Documentation and SDK generation

OpenAPI spec generates interactive documentation, client SDKs, and Postman collections. GraphQL APIs get a Playground with schema documentation.

5. Monitoring and alerting

Deployed APIs include health checks, response time monitoring, error rate alerting, and usage analytics through your cloud infrastructure.

Common questions about API development

Should I build my own auth or use a service like Auth0?

For most startups, start with a managed service (Auth0, Clerk, or Supabase Auth). It handles edge cases like token rotation, multi-factor authentication, and account recovery. Build your own only when you need full control over the auth flow or have compliance requirements that managed services cannot meet.

How do I version my API?

For REST: URL-based versioning (/v1/users) is the simplest and most explicit. For GraphQL: schema evolution with deprecated fields and a sunset timeline. Never break existing consumers without a migration period.

What about API security for mobile apps?

Mobile apps cannot keep secrets. API keys embedded in app binaries are extractable. We use OAuth 2.0 with PKCE for mobile authentication and certificate pinning for additional transport security. Server-side rate limiting protects against abuse.

What does API development cost?

API projects are included in every subscription plan. Simple CRUD APIs fit Minimum 50 (€2,495/month). Complex integrations with Stripe, auth, and third-party services typically need Growth 150 (€5,995/month) or higher. Compare: Freelancer vs Agency vs Subscription.

Can you document an existing undocumented API?

Yes. We reverse-engineer existing APIs, add OpenAPI annotations to NestJS controllers, and generate documentation. This is a common first step when taking over legacy projects. See our guide on Reducing Technical Debt.

Related services

• Node.js Backend: The runtime for your APIs
• React Development: Frontend consuming your APIs
• Next.js Development: Full-stack with server actions and API routes
• TypeScript: End-to-end type safety for your API contracts
• Mobile Development: Native apps consuming your APIs
• Cloud & DevOps: API deployment, monitoring, and scaling