Services
Reliable APIs, imports, exports and data exchange between the business systems your teams already use.
An integration is more than a request and a JSON response. It connects a business action to another system: a website enquiry becomes a CRM case, an order reaches the ERP, a payment provider confirms a transaction, or accounting returns an invoice status.
Before choosing an endpoint, establish what should happen, which system owns the data, who can act and what the team does when an external service is unavailable. An integration is useful only when this process remains understandable in normal operation and during a timeout, duplicate delivery or partial failure.
An API contract describes required data, supported operations, authentication, response formats, errors and versioning. The application should express the business operation; a dedicated integration layer translates it for the provider. That keeps CRM, payment or accounting details out of unrelated order, support and reporting code.
This boundary makes change easier to contain. A new provider or a changed API version affects one integration area, where the contract, mapping and error handling can be tested and monitored.
Two-way synchronization becomes unreliable when two systems both assume they own the same value. For each business field, define the system of record: for example, the CRM for contact details, accounting for invoices, the CMS for published content and the ERP or warehouse for stock.
A one-way update can be straightforward. A two-way update needs a business conflict rule. If CRM and ERP independently change a telephone number, connectivity alone cannot say which is correct. The rule may select the owning system, compare timestamps under defined conditions or send the conflict for review. It should be agreed before production, not improvised after data diverges.
Validate known conditions before an external call: customer identity, order state, currency, permissions and required documents. Then validate the response as external input. HTTP 200 can mean that a request was accepted; it does not always prove that an invoice was created, a payment was settled or an order was completed.
Timeouts create an especially important unknown state. The remote system may have completed the operation but the response may have been lost. For a CRM enquiry, a safe workflow records the local attempt, uses a stable request or business identifier where the provider supports it, checks the remote state when possible, and makes unresolved cases visible to staff.
Idempotency means a repeated request has no additional intended business effect. It relies on the application design and, where relevant, the provider’s idempotency support or a shared identifier. It reduces duplicate risk; it is not a universal guarantee.
A synchronous API call suits a short interaction where the user needs an immediate, bounded answer, such as checking available stock. Imports, document transfer, bulk synchronization and slow providers usually belong in a background job. The application stores the work, reports its status and can continue even when the external system is slow.
Webhooks notify the application that something happened elsewhere, such as payment confirmation. Verify their signature or other authentication, validate the payload, identify duplicates and process them through the same controlled workflow. A webhook receipt is not proof that every downstream business step has succeeded.
Retries should be limited and used for temporary failures. Permanent validation errors need correction, not repeated traffic. Where a provider is repeatedly unavailable, a circuit breaker or temporary pause can protect the application and allow the team to decide when to resume. Recovery may mean a retry, reconciliation with the source system, a compensating action or manual handling, depending on what has already happened.
Use the minimum permissions and data needed for the purpose. Protect secrets in appropriate configuration, restrict access by role and tenant, use secure transport, and keep personal or financial data out of logs unless it is genuinely needed and protected. Authentication confirms the caller’s identity; authorization determines what that caller may do.
Monitoring should show more than technical errors. Teams may need to see pending imports, failed payments, delayed jobs, synchronization conflicts and records requiring review. An audit trail linking the local record, external identifier, request status and final business outcome makes support and reconciliation practical.
A legacy system does not need a wholesale rewrite to integrate reliably. In Symfony or PHP, a small integration service can encapsulate an external client, mapping, validation and error handling. Characterization tests can protect established behaviour before the connection changes. Incremental imports and gradual cutover reduce risk when data quality or ownership is uncertain.
AI services can also be integrated through this boundary, but they should remain proportionate to the process: provide limited approved context, validate structured results and keep permissions and final business actions in the application.
GiSoft designs and improves API integrations around the workflow that matters: CRM, ERP, payments, accounting, imports and partner services. We clarify ownership and contracts, build safe operational paths and make failures visible. The appropriate design depends on the systems, volume, data and business consequences; the aim is dependable exchange, not a claim that external systems never fail.
