api-integration
Defines typed service layers for consistent communication between a Next.js frontend and Django backend.
Install
mkdir -p .claude/skills/api-integration && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/12890" && unzip -o skill.zip -d .claude/skills/api-integration && rm skill.zipInstalls to .claude/skills/api-integration
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Define or review how the Next.js frontend should communicate with the Django REST backend through typed, replaceable service layers.Key capabilities
- →Plan service files and API clients
- →Define endpoint contracts and response typing
- →Review frontend code for backend integration boundary respect
- →Prepare mock-backed frontend flows for real API transition
- →Ensure API communication goes through typed service files
How it works
This skill defines and reviews the communication between a Next.js frontend and a Django REST backend through typed, replaceable service layers.
Inputs & outputs
When to use api-integration
- →Defining API service layers
- →Connecting frontend to Django API
- →Creating typed API contracts
- →Refactoring API calls
About this skill
API Integration
When to use this skill
- When planning service files, API clients, endpoint contracts, or response typing.
- When reviewing whether frontend code respects the backend integration boundary.
- When preparing mock-backed frontend flows to transition cleanly to real APIs later.
Project-specific rules
- The backend is Django REST Framework and the frontend consumes CMS-managed content through REST APIs.
- The API base URL must come from
NEXT_PUBLIC_API_URL. - API communication must go through typed service files.
- Components must not directly call Axios or
fetchfor backend business APIs. - Backend API response shape should follow
{ success, message, data }. - Shared response typing should reflect
ApiResponse<T>. - Keep service ownership split by domain such as menu, reservation, order, gallery, contact, and newsletter.
- Reserve backend authority for reservation conflicts, business validation, and final state decisions.
- If mock data is used, service signatures should remain compatible with later real API replacement.
Expected output quality
- Produces a clean service layer that components can trust.
- Keeps transport concerns, typing, and backend contracts centralized.
- Makes switching from mock data to live APIs low risk.
- Clarifies ownership between UI, service logic, and backend authority.
Things to avoid
- Hardcoding backend URLs in components.
- Returning loosely typed
anyshapes from services. - Letting components know about transport details they should not own.
- Embedding frontend-only assumptions about backend validation.
- Mixing mock and real API logic in a way that is hard to remove later.
Checklist before completing work
- Confirm
NEXT_PUBLIC_API_URLis the only API base source. - Confirm service functions are typed and domain-specific.
- Confirm response handling follows
{ success, message, data }. - Confirm components stay free of direct backend business API calls.
- Confirm backend authority is preserved for validation and conflicts.
When not to use it
- →When hardcoding backend URLs in components
- →When returning loosely typed `any` shapes from services
- →When components directly call Axios or `fetch` for backend business APIs
Limitations
- →Backend is Django REST Framework
- →Frontend consumes CMS-managed content through REST APIs
- →API base URL must come from `NEXT_PUBLIC_API_URL`
How it compares
This workflow standardizes API integration with typed service layers and centralized logic, ensuring a clean transition from mock to live data, unlike direct API calls from components.
Compared to similar skills
api-integration side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| api-integration (this skill) | 0 | 2mo | No flags | Intermediate |
| htmx-patterns | 0 | 4mo | No flags | Intermediate |
| sigma-audio-crm | 0 | 2mo | Caution | Advanced |
| hr-portal-skill | 0 | 1mo | No flags | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by anubhavnepal
View all by anubhavnepal →You might also like
htmx-patterns
rhbpinheiro
HTMX + Django patterns for interactive UX without JavaScript complexity. Avoid JS conflicts using HTMX as single source of interactivity.
sigma-audio-crm
YuvrajGaykhe
Use this skill for ALL development, debugging, review, refactoring, feature building, and integration work on the Sigma Audio Dealer & Sales Intelligence Platform. Trigger whenever the user mentions leads, dealers, follow-ups, RBAC, CRM, audit logs, Kanban pipeline, analytics, sales executive, Djang
hr-portal-skill
hariventures2000-ship-it
Use this skill when developing, testing, debugging, or modifying code inside the HR Portal frontend (apps/hr-portal). It applies to handling HR administration tasks such as employee roster management, contract seeding, leave request approvals, attendance monitoring, payroll calculation, and recruitm
dapp
salazarsebas
Stellar dApp / frontend development. Covers the JavaScript stellar-sdk (browser + Node.js), Freighter wallet, Stellar Wallets Kit (multi-wallet), Wallet Standard, smart accounts with passkeys, transaction building / signing / submission, Soroban contract invocation from the client, simulation, and e
dynamic
LowyShin
|
backend-dev-guidelines
langfuse
Comprehensive backend development guide for Langfuse's Next.js 14/tRPC/Express/TypeScript monorepo. Use when creating tRPC routers, public API endpoints, BullMQ queue processors, services, or working with tRPC procedures, Next.js API routes, Prisma database access, ClickHouse analytics queries, Redis queues, OpenTelemetry instrumentation, Zod v4 validation, env.mjs configuration, tenant isolation patterns, or async patterns. Covers layered architecture (tRPC procedures → services, queue processors → services), dual database system (PostgreSQL + ClickHouse), projectId filtering for multi-tenant isolation, traceException error handling, observability patterns, and testing strategies (Jest for web, vitest for worker).