API Development for Shop, ERP and Accounting
We design, implement and document REST and GraphQL APIs that connect your online shop with ERP, PIM, CRM and accounting. Every interface is dimensioned for your data volumes, secured with OAuth 2.0 and fully documented.
GoBD
compliant document transfer
OAuth 2.0
secured API access
< 50 ms
target API response time
50+
integration projects
Billing · net plus VAT
- Transparent billing by effort instead of a shot-in-the-dark flat fee
- REST and GraphQL, versioned and documented with OpenAPI 3.0
- OAuth 2.0, rate limiting and granular scopes out of the box
- Webhooks, retry and dead-letter handling for stable data flows
Project day 990 € net. A compact REST or GraphQL connection with a few endpoints typically lands in the low five-figure range, while comprehensive API platforms with their own transformation layer sit above. Binding scope after the free interface analysis. All prices net plus VAT. The project day is a package price for a reserved working day and therefore deliberately not a multiple of the hourly rate — the rationale is on the pricing overview.
Not every system provides the interfaces your integration project requires. Existing APIs are often too granular, too slow or functionally incomplete. Our API development closes these gaps: we design, implement and document tailored REST and GraphQL APIs that serve as a mediation layer between your shop and connected systems. Whether SAP connectivity, DATEV integration or connecting with a PIM system — every API is precisely tailored to the data flows and performance requirements of your project and billed transparently by effort.
Architecture of a Production Shop API
REST vs. GraphQL: The right architecture for your use case
The choice between REST and GraphQL is not an ideological decision but a technical one. Both architectures have specific strengths. In many of our projects, we deploy both technologies in parallel, each where they provide the greatest advantage.
| Feature | REST API | GraphQL API |
|---|---|---|
| Data querying | Fixed endpoints with predefined data structure | Flexible queries, client determines data structure |
| Network load | Frequently over-fetching or under-fetching | Exactly the needed data, minimal network load |
| Caching | HTTP caching natively supported (ETags, Cache-Control) | Requires custom caching strategy |
| Documentation | OpenAPI/Swagger as de facto standard | Schema-based self-documentation |
| Best suited for | CRUD operations, standard data flows, broad compatibility | Complex queries, variable data needs, mobile scenarios |
Our recommendation
Six quality characteristics of our APIs
Authentication and Authorization
OAuth 2.0 with Client Credentials for server-to-server communication and Authorization Code Flow for user-based access. API keys as fallback for simpler scenarios. Role-based access control at endpoint level.
Rate Limiting and Throttling
Configurable rate limits per API key, endpoint and time window. Token bucket algorithm for even load distribution. Transparent communication of limits via HTTP headers (X-RateLimit-*).
Versioning
URL-based or header-based versioning for parallel operation of old and new API versions. Deprecation policy with defined sunset periods and automatic consumer notification.
OpenAPI Documentation
Every REST API ships with a complete OpenAPI 3.0 specification. Interactive documentation via Swagger UI, Postman collections and code generators for common programming languages.
Monitoring and Logging
Every API call is logged: request, response, latencies and errors. Dashboards visualize usage patterns, performance metrics and error rates. Automatic alerts on threshold exceedances.
Error Handling and Retry
Structured error responses with machine-readable error codes and human-readable descriptions. Idempotent endpoints enable safe retry of failed requests. Webhooks for asynchronous notifications.
Secure authentication with OAuth 2.0
Multi-layered API security
Security is an architectural foundation for us, not a retroactive feature. At the transport level, we encrypt all transfers via TLS 1.3. At the application level, we use OAuth 2.0 with short-lived access tokens and refresh token rotation. Rate limiting protects against overload, IP whitelisting restricts access to known servers. Granular scopes ensure every consumer sees only the data relevant to its purpose: the shop connector sees products and prices, the DATEV connector sees invoices and payments.
- TLS 1.3 for all transfers
- OAuth 2.0 with refresh token rotation
- Granular scopes per consumer
Webhooks and Event-Driven Architecture
Beyond classic request-response APIs, we implement webhook-based event systems that send push notifications to registered endpoints when relevant events occur. When a product is updated in the ERP, the API sends a webhook to the shop, which then updates the product data. This pattern eliminates regular polling queries, reduces latency and lowers network load.
Automatic retries
Failed deliveries are retried with exponentially growing wait times until the target system is reachable again.
Signature verification
Every webhook carries an HMAC signature the recipient verifies to reliably rule out spoofing.
Dead-letter handling
Undeliverable events land in a dedicated queue with full context and can be reprocessed after the root cause is fixed.
Webhook management
Register, deactivate and test endpoints via an interface. Combined with message queues, this creates a fully event-driven architecture.
From concept to production API: our approach
- 1
Requirements analysis
We capture the consuming systems, expected data volumes and requirements for availability and latency. From this comes the decision for REST, GraphQL or event-based.
- 2
API design
The domain model determines the resource structure, not the database. Endpoints represent business objects. Pagination and cursor navigation are built in from the start.
- 3
Implementation and testing
Unit tests secure the business logic, integration tests the connectivity, load tests the performance and contract tests the backward compatibility toward existing consumers.
- 4
Documentation and handover
OpenAPI specification, Swagger UI, Postman collections and an architecture document. In onboarding sessions, we explain design decisions and integration patterns.
- 5
Operation and monitoring
Structured logging, distributed tracing and metrics. Alerts on anomalies. Quarterly reviews of performance, error rates and usage patterns.
What API Development Costs
A rough ballpark figure is of little use for budget planning. That is why we bill API development transparently by effort — at 990 € net per project day or hourly at 119 € net. After a free interface analysis, you receive a binding scope with no hidden items. A compact REST or GraphQL connection with a few endpoints typically lands in the low five-figure range, while comprehensive API platforms with their own transformation layer sit above.
Billing for Your API Development
All prices net plus VAT. Every build starts with a free interface analysis and a binding scope.
API Assessment
Review of existing APIs or a concept for new interfaces.
- Architecture, performance and security review
- Assessment of documentation and versioning
- Action plan with effort estimate
- Typically one to two person-days
- Result as a solid decision basis
API Development
Custom REST or GraphQL API by effort, project day 990 € net.
- REST and GraphQL, versioned and documented
- OAuth 2.0, rate limiting and granular scopes
- OpenAPI 3.0 with interactive documentation
- Webhooks, retry and dead-letter handling
- Compact connection usually in the low five-figure range
Operation & Monitoring
Ongoing support, extension and monitoring of your APIs.
- Monitoring of throughput, latency and error rate
- Quarterly reviews of performance and usage
- Extension with new endpoints and versions
- SLA-based response times as agreed
- Billed hourly at 119 €
We are happy to give ballpark figures up front: a single REST connection with a few endpoints usually lands in the low five-figure range, a comprehensive API platform acting as a central data hub above. The binding scope follows the free interface analysis. All prices net, plus VAT.
Unsure which API architecture your project needs?
In a free initial consultation, we analyze your system landscape and recommend the right solution technology-neutrally.
Long-lived interfaces through clean design principles
A well-designed API outlives multiple generations of frontend applications. Backward compatibility is particularly important: new fields are added as optional, never introduced as required. Existing fields are never removed, only marked as deprecated at most. When a breaking change is unavoidable, a new API version is introduced while the old one continues operating for a defined period.
- The domain model determines the resource structure, not the database tables
- Consistent naming and predictable URL structures
- Standards-compliant HTTP status codes and meaningful error messages
- Pagination and cursor navigation built in from the start
- Versioned changelogs inform about new endpoints and deprecations
- Automated tests keep specification and implementation synchronized
API development in the context of the overall architecture
APIs are never isolated. They are part of an integration architecture connecting ERP, shop, middleware and third-party systems. An API that performs well in isolation can become a bottleneck when combined with synchronous ERP connectivity if ERP response times fluctuate. In such cases, we recommend asynchronous patterns with message queues that decouple endpoint latency from ERP performance. Our experience spans focused single interfaces as well as comprehensive API platforms acting as central data hubs of professional interface development.
An undocumented API is technical debt that multiplies with each integration. Clean design, comprehensive testing and complete documentation are not options but fundamental prerequisites.
Frequently asked questions about API development
Technical deep dives on the blog: API Versioning describes strategies for backward-compatible interfaces, OAuth 2.0 and Token Security explains how ERP access is secured, and Webhooks vs. Polling compares push and pull models for event data.