ERP and inventory systems
Exchange products, prices, stock, customers, orders or documents while preserving the authority of the source system for each field.
API development and system integration
Connect business systems with data flows you can monitor, understand and recover.
ProWebSolutions develops and improves integrations between ecommerce platforms, ERP and inventory systems, CRM, PIM, payment and shipping providers, marketplaces and internal applications. The work covers validation, state, retries, logging and recovery when a process cannot finish automatically.
Operating reality
Connected systems can still leave people doing manual repair work
Moving a payload from one endpoint to another is rarely the whole task. An order may arrive twice, a stock update may contain an unknown item, or a timeout may occur after the receiver has already saved the request. A technically successful response can still contain the wrong business result.
An integration becomes useful when the responsible teams can see what was processed, what remains open and how a failed item returns to the workflow. That requires business rules and operating decisions alongside implementation.
Common integration scenarios
Different systems, one need for visible process state.
CRM and PIM
Synchronise customer and product information with stable identifiers and rules for conflicting changes.
Payment and shipping providers
Verify messages and assign status updates to the correct transaction, including duplicated or delayed delivery.
Marketplaces and product feeds
Process offers, availability and orders under channel-specific formats, limits and business rules.
Internal and file-based processes
Connect specialist workflows through an API, webhook, scheduled import or validated CSV/XML exchange.
Data ownership
Begin with responsibility for the data
Before fields are mapped, each participating system needs a defined role. Which application owns a product name? Where does the final payment status originate? What happens when two sources disagree?
A data contract captures objects, required fields, formats, units, identifiers, allowed states, volumes, timing and versioning. It also records decisions such as whether an unknown item blocks an order and how a corrected record is submitted again. Otherwise, unresolved ownership tends to reappear as scattered mapping code and misleading transport errors.
Processing stages
The data path needs explicit stages
Authentication and authorisation
The connection establishes who may send, read or change data. Tokens, signatures and permissions need a lifecycle that fits the participating services.
Technical and business validation
Technical validation checks structure and data types. Business validation asks whether a state change is allowed, a referenced record exists or a total is plausible.
Mapping and identity
Units, time zones, currencies, external identifiers and status meanings determine whether information has the same meaning in both systems.
Processing and state
The implementation decides whether a record is new, whether an update is allowed and what happens after partial success. A visible state model replaces a binary worked-or-failed view.
Logging and operational status
Correlation and business identifiers connect time, operation, result, duration and error category without requiring complete payloads in logs.
Transport choice
API call, webhook or batch import?
Direct API request
- Immediate request and response
- Suitable for targeted queries or changes
- Timeouts and rate limits need a response path
Webhook or event
- Triggered when something changes
- Avoids unnecessary polling
- Requires authentication and duplicate handling
Scheduled batch or file exchange
- Suitable for larger volumes or legacy systems
- Each record needs a processing status
- Recovery must distinguish failed and successful subsets
Repeatable processing
Retries must not create duplicate business actions
Temporary network faults, rate limits and service interruptions are normal in distributed systems. Attempts should be limited, spaced appropriately and connected to a visible failure state.
Retry only when another attempt can help
A temporary outage may resolve; an invalid required field will not improve after ten attempts. The retry also needs enough context to know whether the original operation is still valid.
Idempotency protects against duplicate effects
A stable external ID or idempotency key lets a receiver recognise the same business operation and return the existing result instead of creating a duplicate order or booking.
Recovery
Partial success needs a recovery model
A database transaction can group local changes, but it cannot automatically roll back an action already performed by a payment, ERP or shipping system. An integration therefore needs explicit states for completed steps and a decision for each failure: retry, compensate or send the item to manual review.
For batches, valid records can sometimes proceed while invalid ones remain open. In other processes, dependencies require the whole group to stop. The suitable behaviour follows the business rules and must be testable.
Observability
Observability combines technical and business signals
Response times, error rates and queue length show technical health. Business checks reveal that no orders have been transferred for two hours, that stock updates are falling behind or that an unusual number of products lacks a category.
One layer cannot replace the other. A reachable API may receive no data, and a growing queue may be expected during a planned import. Alerts need context, thresholds and a named response path within the agreed operating scope.
- Missing or malformed required fields
- Invalid business-state changes
- Duplicated and out-of-order messages
- Timeouts after processing
- Rate limits and temporary failures
- Partial batch results
- Restart after an interrupted process
- Contract-version changes
Existing integrations
Taking over an existing integration
An inherited connection often needs visibility before its mapping logic is changed. Relevant inputs include the data contract, schedules, logs, recurring error patterns, correction routines and the people responsible for both systems.
The first improvement may be a transaction status or usable correlation ID rather than a new endpoint. Once real failures can be classified, logic changes can be prioritised against evidence from day-to-day operation.
Operational readiness
Before the integration enters normal operation
Authentication, secret rotation, limits, timeouts, retries, idempotency, log access, monitoring, data protection, responsibilities and a recovery route should be addressed within the agreed scope. The plan should also cover data that accumulates during an outage.
After launch, source and target control values help verify that assumptions based on test data hold under real conditions. Processing times and error categories then become part of the normal operating picture.
Make the current failure mode the starting point
Share the source and destination systems, the relevant data, approximate volumes and what currently goes wrong. That is enough to identify a practical starting point without sending credentials or confidential datasets.