Implementation
Connect an existing API
Your application exchanges one clearly defined data type with an existing service, including error handling and documented handover.
Backend & applications
Backend for clearly defined processes.
An order needs to reach a shipping tool. A customer may view only their own documents. We develop the rules behind these processes and connect them to your existing application.
Browse services in the shop View a work sampleWhich rules must the system enforce?
An integration transfers more than fields. It needs to know which system holds the authoritative version, who may change it and what happens on a retry. We describe the rules using a specific transaction. That defines the function's scope and the cases to test.
Map data reliably
A unique identifier connects transactions across systems. Required fields, conflicts and duplicate transfers need defined behaviour.
Check access in the backend
The server decides whether someone may read a file or change a transaction. Hiding a button does not restrict access on its own.
Fictional working example
An order arrives twice
A fictional integration transfers orders to a shipping tool. After a delayed response, the same order is sent again.
The change
A stable transaction identifier makes the repeat recognisable. The backend handles it according to the agreed rules and records failed transfers traceably.
How we check
Tests cover the normal transaction, a second identical transfer and a temporary destination outage. The expected outcome is defined for each case beforehand.
The rule behind the button.
An interface can make a process look simple while several rules apply behind it. An appointment can be assigned only if a resource is available. A document belongs to a specific customer. Resubmitting a transaction should not accidentally create another order. These rules are implemented on the server and described using specific cases.
Before development, we establish authoritative data and permitted actions. This includes handling invalid entries and competing changes. Expected responses are defined for normal and failing flows. The interface can then give understandable feedback rather than an unclear technical error.
Build a backend featureSuitable services
All services on this topic Where should you start?
Connect two existing systems
API integration fits when source, destination and intended data exchange are defined. Existing APIs and access rights are clarified before work starts.
Extend an application
For a new rule or feature in an existing backend, we agree a defined scope including the relevant failure cases.
Implementation
Build a backend feature
We implement one clearly described business process on the server, with rules, storage and documented failure cases.
Keep systems connected.
An integration is about more than the first successful transfer. External systems may respond slowly, reject individual fields or become temporarily unavailable. The integration needs retry rules and traceable errors. Whether data flows one way or can change on both sides also significantly affects scope.
Who notices when a transaction gets stuck? Answer that before starting. An existing error log and documented retry process may be sufficient; other applications need a notification. Responsibility must be clear, otherwise even a well-recorded error remains unresolved.
Read the guideHow we work
Describe a transaction completely.
Define data and rules
We walk through a specific transaction: what arrives, which system has the authoritative version and who may change it? Then we consider exceptions such as missing fields or cancellation. We record the required system response for each case.
Develop a scoped function
The function is integrated into the existing application. The backend validates inputs and permissions before changing data. External services follow the agreed error and retry rules.
Trigger exceptions deliberately
We resend the same transaction, omit required fields and check missing permissions. For external services, we also consider missing responses. Tests compare these cases with the behaviour defined earlier.
Hand over operations
Who releases the change, sees errors and can reprocess transactions? These responsibilities are handed over with the configuration. The feature remains maintainable beyond its first successful run.
A normal transaction
Describe the trigger, available data and intended result. An anonymised example with an expected response makes terms and field mappings tangible without exposing real customer information.
Known exceptions
What should happen to a duplicate order, cancellation or missing permission? Describe the expected outcome. 'Handle errors' is insufficient if it remains unclear whether someone may retry afterwards.
Existing environment
API documentation, data model and release process help define scope. For external systems, we need details of test access and limitations. Secrets are exchanged separately.
Can you extend an existing application?
Yes, provided the access and technical requirements are settled. We review the affected area and its dependencies. A complete rebuild is separate work.
Which materials help before starting?
A process description, existing API documentation and anonymised sample data are useful. Credentials are exchanged only through an agreed channel.
Are operations and monitoring included?
Developing a feature and operating it have different scopes. Handover, error reporting, responsibility and possible support are agreed before commissioning.
An integration or a new feature?
For exchange between two existing systems, choose API integration. If the application itself needs a new rule, start with backend feature development. A client portal usually combines several such tasks and needs more detailed planning.
If a third-party API lacks documentation, its capabilities must be established first. Without a test system, another verification method is needed. Mention such limits in your enquiry: they determine how we develop and check the change before use.
Further reading
