An API developer builds and maintains the interfaces that let software systems exchange data and trigger actions. The difficult part is rarely exposing an endpoint. It is deciding what happens when a payment request arrives twice, a user requests another customer’s data, an external provider times out, or an old mobile app still depends on an earlier API version.
For CTOs and product leaders, an API is a contract between systems. Poor access control, unclear failure behaviour, or careless changes can affect every application and integration that depends on it.
What does an API developer do?
The work typically covers:
- designing API contracts and choosing suitable protocols
- implementing authentication and access control
- connecting applications, databases, and external services
- handling validation, errors, retries, and version changes
- testing interfaces and monitoring production behaviour
Code & Pepper’s API development services cover custom APIs and third-party integrations, including systems connected to payments, banking data, credit scoring, KYC, AML, analytics, and accounting.
API development starts with the contract
A good API contract defines what consumers can request, what the server returns, what can fail, and how the interface can change without breaking consumers.
Consider:
POST /payments
Before implementation, the engineer needs answers to questions such as:
- How is the amount represented?
- Which currencies are accepted?
- Who can initiate the payment?
- What happens if the request arrives twice?
- Can a timed-out request be retried safely?
- Which errors are safe to expose?
- Is processing synchronous or asynchronous?
- How does the client learn that a pending payment failed later?
- Can the response change without breaking older clients?
These decisions matter more than the controller code itself.
The OpenAPI Specification provides a language-agnostic description format for HTTP APIs. Its latest published version is 3.2.0, released on September 19, 2025.
A contract-first workflow defines the interface before implementation. Frontend engineers can work against mocks, QA can derive tests, and automated checks can detect some incompatible changes before release.
API design should involve consumers early. Code & Pepper’s August 2026 article on what a React.js developer does looks at the frontend side of this relationship. Web and mobile applications depend on predictable contracts for data, permissions, authentication, and errors.
REST, GraphQL, gRPC, webhooks, or asynchronous messaging?
The right communication model depends on who consumes the service, what guarantees they need, and how tightly the systems should be coupled.
| Approach | Good fit | Main trade-off |
| REST | Public APIs, resource-oriented systems, broad interoperability | Clients may need several requests or receive more data than needed |
| GraphQL | Client-driven queries and connected data | Query complexity and authorisation require careful control |
| gRPC | Typed service-to-service communication | Browser and public API use can require extra infrastructure |
| Webhooks | Sending events to external systems | Delivery, retries, signatures, duplicates, and ordering need explicit handling |
| Async messaging | Work that does not require an immediate response | Event schemas, retries, ordering, and eventual consistency add complexity |
GraphQL is not simply a newer REST. It lets clients specify the shape of the data they need. The current stable GraphQL specification is the September 2025 Edition.
A product can use several approaches at once. A web application might use GraphQL, internal services might communicate through asynchronous events, and external partners might receive webhooks.
Start with the communication problem. Then choose the protocol.
API security starts with authorisation
A secure API must check both identity and permission.
Authentication answers:
Who are you?
Authorisation answers:
Are you allowed to access this resource?
Consider:
GET /accounts/8472/transactions
A valid token can prove that a user authenticated. It does not prove that the user should be allowed to read account 8472.
This distinction matters because an attacker may already have a valid account. Changing an object identifier should not allow that user to retrieve another customer’s records.
The OWASP API Security Top 10 ranks Broken Object Level Authorization as API1 in its 2023 edition. OWASP recommends object-level permission checks whenever an endpoint accesses an object through an identifier supplied by a client.
OAuth implementations also need current security guidance. RFC 9700, published in January 2025, defines OAuth 2.0 Security Best Current Practice. It covers areas such as redirect URI validation, PKCE, token protection, and secure communication.
For browser clients, RFC 10017, OAuth 2.0 for Browser-Based Applications, was published in August 2026 and provides dedicated guidance for browser applications.
For FinTech, HealthTech, and InsurTech products, these controls also need to fit the applicable legal, regulatory, security, and data-handling requirements. Following a technical standard does not by itself prove regulatory compliance.
The technical lesson that prevents duplicate transactions
Retries and idempotency need to be designed together because a timeout does not tell the caller whether an operation completed.
Suppose an application sends:
POST /transfers
for a $1,000 transfer.
The server processes the transfer, but the response is lost. The client sees a timeout.
If the client blindly repeats the request, it could create another transfer. If it never retries, the customer may be left with an unknown result.
An idempotency key helps resolve this problem. The client assigns a unique identifier to the operation. If the same request arrives again with that key, the server can recognise the existing operation rather than create another one.
That does not make the design automatic. The team still needs to decide:
- how long idempotency keys remain valid
- where their state is stored
- what happens if the same key arrives with different request data
- how concurrent duplicates are handled
- whether the downstream provider offers equivalent protection
- what response is returned while processing continues
- how uncertain states are reconciled later
This is why API engineering is about failure semantics, not endpoint count. For financial products, knowing what happened after an uncertain response can be as important as processing the original request.
Third-party integrations need different engineering
An external API is a dependency whose availability, limits, behaviour, and release schedule are outside your control.
Providers can time out. Rate limits can change. Credentials expire. Webhooks can arrive twice. A provider may change a schema. A sandbox may not reproduce production behaviour accurately.
A production integration therefore needs explicit rules for:
- timeouts
- retries and backoff
- rate limiting
- credential rotation
- webhook verification
- duplicate events
- schema validation
- provider-specific errors
- observability
- version changes
- reconciliation after partial failures
One common mistake is retrying every failed operation.
Repeating a failed GET may often be safe. Repeating a request that creates a payment, policy, order, or transfer requires more care because the first request may already have succeeded.
DirectID: replacing an Open Banking provider
Code & Pepper encountered this type of integration problem while working with DirectID and Salt Edge.
The product already communicated with Yodlee, while Salt Edge represented some data differently. Code & Pepper created an analogous integration layer so the new provider could fit the existing architecture.
The published project covers OAuth, providers, accounts, account holders, transaction history, additional security data, and a three-layer architecture. Testing included xUnit, FakeItEasy, and Polly, including retry scenarios.
Read the DirectID and Salt Edge API integration case study for the project details.
The architectural lesson extends beyond Open Banking. Provider-specific behaviour should be isolated where practical. Adding or replacing a provider should not require changes throughout the product.
API engineering in FinTech and InsurTech
Regulated products increase the cost of weak interface decisions because APIs can sit directly on sensitive data and critical workflows.
A banking interface may expose accounts and transactions. An insurance platform may connect policy administration, payments, identity, vehicle data, and risk systems. Health software may expose sensitive records that require strict access rules and traceability.
These constraints affect architecture. Authentication, authorisation, auditability, data handling, external dependencies, failure recovery, and operational monitoring need to be considered during API design rather than added after implementation.
CoverTree provides a Code & Pepper example from InsurTech. The US platform required integrations with external systems for policy management, payments, vehicle-registration data, and risk assessment.
Code & Pepper used an AWS serverless architecture with TypeScript, Node.js, AppSync, DynamoDB, Cognito, GraphQL, and Cypress.
The project shows why API decisions cannot be separated from identity, data storage, cloud architecture, testing, and external dependencies.
See the CoverTree InsurTech case study for the published implementation details.
Code & Pepper’s June 2026 guide to backend technologies provides more context on server-side technology choices. The stack should follow product constraints, dependencies, operating requirements, and the skills of the team maintaining it.
What skills should an API engineer have?
A strong API engineer can reason about system boundaries when requests fail, permissions become complex, or contracts need to change.
| Skill area | What to look for |
| Backend development | Production experience with Node.js/TypeScript, Python, Java, Go, .NET, or another suitable stack |
| Interface design | REST semantics, GraphQL or gRPC where relevant, pagination, filtering, errors, versioning |
| Specifications | OpenAPI, JSON Schema, GraphQL schemas |
| Security | OAuth 2.0, OIDC where relevant, token validation, authorisation, secrets, rate limiting |
| Data | SQL or NoSQL modelling, transactions, consistency, caching |
| Testing | Unit, integration, contract, end-to-end, and failure-path tests |
| Integration | Timeouts, retries, idempotency, webhooks, provider failures |
| Operations | Logging, metrics, tracing, alerts, incident debugging |
| Delivery | Git, CI/CD, containers, cloud platforms, API gateways |
| Communication | Clear documentation and collaboration with API consumers |
For senior candidates, test these skills with production scenarios rather than framework trivia.
Ask what should happen when a payment request times out after the provider may have processed it. A strong answer should cover idempotency, provider guarantees, retries, reconciliation, and monitoring.
Ask how the candidate would prevent an authenticated user from accessing another customer’s transactions by changing an account ID. The answer should include object-level authorisation rather than relying on authentication alone.
Then ask how they would introduce a breaking response change while an older mobile application still uses the existing version. Look for compatibility, versioning, deprecation, consumer communication, monitoring, and migration.
These scenarios show how an engineer reasons when the correct answer depends on system behaviour rather than syntax.
API engineer vs backend developer
The roles overlap, but their emphasis differs.
| Backend engineer | API-focused engineer |
| Domain and application logic | Interface contracts |
| Database access and data processing | Request and response design |
| Queues and workers | Consumer-facing errors |
| Caching and internal services | Access-control boundaries |
| General server-side architecture | Versioning and compatibility |
| Infrastructure integrations | Partner and provider integrations |
In a startup, one engineer may cover both areas. Larger products may separate API, integration, platform, governance, or developer-experience responsibilities.
Code & Pepper’s back-end development services cover the wider server-side layer. For a closer look at one common backend stack, see the July 2026 guide to what a Node.js developer does.
The title matters less than ownership. If an engineer owns a public or partner-facing interface, they need to think about consumers, compatibility, failure semantics, permissions, and operational behaviour even if their job title says backend engineer.
How much does an API developer earn?
In August 2026, ZipRecruiter reported an average US API Developer salary of $124,567 per year, or $59.89 per hour. It reported the 25th-to-75th-percentile range at $113,500 to $140,000.
UK data is thinner. Glassdoor reported average base pay of about £44,000 per year, with a £34,000 to £57,000 range. Its UK estimate was based on a small salary sample, so it is better treated as a directional benchmark than a precise market rate.
Location, seniority, stack, domain expertise, security requirements, and ownership of production systems can all affect compensation.
How much does API development cost?
API development costs vary because scope, security, external dependencies, and operational requirements can differ substantially between projects.
Rather than treating endpoint count as the main pricing unit, estimate the work required across design, implementation, integrations, testing, security, deployment, and production support.
| Project scope | What typically drives the cost |
| Focused API or integration | Defined business logic, one main system or provider, established authentication, limited migration |
| Multi-system integration | Several providers, data mapping, webhooks, retries, reconciliation, monitoring |
| Complex API platform | Multiple consumers, fine-grained permissions, high availability, versioning, security requirements, operational tooling |
A small API can still be expensive if it handles payments or sensitive data. OAuth flows, idempotency, webhook verification, reconciliation, auditability, migration, and failure recovery can require more engineering than dozens of straightforward CRUD endpoints.
Hourly-rate benchmarks can provide some context for budgeting, but they do not produce a reliable project price on their own. The final cost depends on the team composition, location, delivery model, existing architecture, QA scope, infrastructure, and post-release responsibilities.
For a useful estimate, define what the quote includes. At minimum, check the scope of:
- API and data-model design
- backend implementation
- third-party integrations
- authentication and authorisation
- automated testing
- security work
- documentation
- deployment and infrastructure
- logging, monitoring, and alerting
- migration and backward compatibility
- post-release support
This is why a credible API development estimate usually follows technical discovery. A fixed project range given before the architecture, dependencies, security constraints, and failure scenarios are understood can create false precision.
How long does API development take?
Delivery time follows scope and risk rather than the number of routes in the specification.
A small internal interface with established authentication, clear business rules, no migration, and few dependencies may move quickly. A financial integration with OAuth, webhooks, money movement, provider limitations, reconciliation, strict permissions, and existing consumers requires more engineering even if it exposes fewer endpoints.
Before accepting a delivery estimate, clarify:
- Is the interface new or replacing an existing one?
- Who consumes it?
- Which external providers are involved?
- How useful are their documentation and test environments?
- What authentication and permission model is required?
- Are operations synchronous, asynchronous, or both?
- Which failure and retry cases matter?
- Does existing data need migration or reconciliation?
- What testing and security review are required?
- Do existing consumers need a migration period?
- Who owns monitoring and incidents after launch?
A useful delivery plan should follow those answers.
If a vendor gives a fixed delivery window before understanding these constraints, ask what assumptions sit behind the number.
When should you bring in external API expertise?
External engineering support makes sense when integration work blocks product delivery, creates production risk, or consumes too much of the core team’s senior engineering capacity.
Common triggers include:
- a payment or Open Banking integration is delaying release
- several providers need one consistent internal interface
- authentication or permissions need redesign
- a provider must be replaced without breaking consumers
- frontend or mobile teams are blocked by unstable contracts
- partner onboarding is slowed by unclear API behaviour
- production incidents expose weak retry or reconciliation logic
- an external API needs stable versioning and operational ownership
- your team lacks experience with a provider, protocol, or architecture
Hire API developers from Code & Pepper if API work is blocking a release, slowing partner integrations, or pulling senior engineers away from core product work.
Bring us a new API, a complex third-party integration, a provider migration, or an existing interface that needs redesign. We can help you define the technical scope and add engineers with relevant backend, integration, and regulated-product experience.
Code & Pepper has worked on API-heavy FinTech and InsurTech products, including DirectID’s Open Banking integration and CoverTree’s external-system architecture. Its FinTech software development services also cover products connected to banking, payments, credit scoring, KYC, AML, analytics, and accounting systems.
If the API layer is now a delivery risk, treat it as one. Fix the architecture, remove the integration bottleneck, and give your product team a stable interface they can keep building on.
What makes an API difficult to build?
Complexity usually comes from business rules, permissions, external dependencies, failure handling, compatibility, data consistency, and production requirements rather than endpoint count.
Do API developers need frontend skills?
They do not need to specialise in frontend development. Understanding how web and mobile clients consume APIs does help them design clearer contracts, authentication flows, errors, and version changes.
Do API developers work with databases?
Yes. API work often involves retrieving, validating, updating, and protecting data stored in SQL or NoSQL databases. Engineers also need to understand transactions and consistency when several operations affect the same business process.
Which programming languages are used for API development?
Common choices include TypeScript or JavaScript with Node.js, Python, Java, Go, C#, and Ruby. The right choice depends on the existing stack, performance requirements, libraries, deployment environment, and team expertise.
When should an API be versioned?
Versioning becomes relevant when a change cannot be introduced without breaking existing consumers. Teams should first check whether the change can remain backward compatible before creating another version.
What is API contract testing?
Contract testing checks whether providers and consumers still agree on requests, responses, schemas, and expected behaviour. It can catch integration problems before independently deployed systems meet in production.
What is the difference between authentication and authorisation in an API?
Authentication establishes who the caller is. Authorisation determines what that caller is allowed to read or change. A valid access token does not automatically grant access to every resource behind an endpoint.
When do you need a dedicated API engineer?
A dedicated specialist becomes useful when partner integrations, complex permissions, versioning, provider dependencies, or production reliability are taking significant time from the wider backend team.