Third-party and API integration
APIs and third-party services joined up, with the failure cases handled
REST, SOAP, webhooks and iPaaS integrations with CRM, logistics, tax, KYC and identity providers.
Overview
Most businesses depend on services they do not run: a CRM, carriers, tax and e-invoicing platforms, identity and KYC providers, marketplaces and SaaS tools. Each has its own API, its own limits and its own way of failing. Connected one at a time, they become a set of scripts nobody fully understands.
We design and build integrations over REST, SOAP, GraphQL and webhooks, directly or through an integration platform such as MuleSoft, Boomi or Azure Logic Apps. We connect identity too: single sign-on with OpenID Connect or SAML, user provisioning with SCIM, and service access with OAuth 2.0.
Every call is designed for the day the other side fails. We use idempotent requests so a retry never creates a duplicate, retries with back-off for temporary faults, and a dead-letter queue with alerts for the rest. Contracts are written down, versions are managed, and your team can see what moved and what did not.
What we deliver
Integration inventory
Every third-party service you depend on, what data flows to and from it, and who owns each connection.
API contracts
OpenAPI or WSDL definitions for each interface, with field rules, error codes, limits and examples.
Connectors
The code or integration-platform flows that call each service and handle its callbacks, built and tested.
Identity and single sign-on
Sign-in through your identity provider with OpenID Connect or SAML, and user provisioning with SCIM where it is supported.
Retries, idempotency and dead letters
Safe retries for temporary faults, duplicate protection on every write, and a queue for messages that still fail.
Versioning and change policy
A versioning scheme for the APIs you publish, and a process for absorbing changes in the APIs you call.
Secrets and access
Credentials and keys in a secrets store, scoped to each integration and rotated on a schedule you set.
Monitoring and alerts
Traces, error rates and latency per partner, with alerts that say which partner failed and how.
Contract and integration tests
Automated tests against each contract and each partner’s test environment, run before every release.
How we work
- 01
Take stock
We list the services you depend on, the data each one needs and the failures you see today.
- 02
Design the contracts
We write the API contracts and choose direct calls, events or an integration platform for each flow.
- 03
Build the connectors
We build each connector with its error handling, duplicate protection and logging in place from the start.
- 04
Test with each partner
We run contract tests and end-to-end scenarios in each partner’s test environment, including failures.
- 05
Release safely
We release behind feature flags or in stages, and keep the old path available until the new one is proven.
- 06
Run and adapt
We watch error rates and dead letters, and adapt the connectors when partners change their APIs.
How it connects
Scroll sideways to see the whole drawing.
ERP to third parties: one platform, many partners
Business events leave the ERP once and the integration platform delivers them to each partner in the format it expects. Callbacks come back the same way. A message that still fails after its retries goes to a dead-letter queue and raises an alert with the payload attached.
- Primary flow
- Asynchronous
- Exception path
The flow, step by step
- From ERP to Integration platform: Business events, over REST · OData · webhook (primary flow).
- From Integration platform to CRM: Customers and orders, over REST/JSON (primary flow).
- From Integration platform to Logistics and carriers: Shipments booked, over REST/JSON (primary flow).
- From Logistics and carriers to Integration platform: Tracking events, over webhook (asynchronous).
- From Integration platform to E-invoicing and tax platform: Invoices for clearance, over SOAP/XML · REST (primary flow).
- From Integration platform to KYC and identity provider: Identity checks, over REST/JSON (primary flow).
- From KYC and identity provider to Integration platform: Check results, over webhook (asynchronous).
- From Integration platform to Dead-letter queue and alerts: Failed after retries, to a dead-letter queue (exception path).
- From Dead-letter queue and alerts to Support team: Alert with the payload and the error (exception path).
Technologies
- Data and analytics
- Apache Kafka
- Testing
- Postman
- Integration
- REST
- SOAP
- GraphQL
- Webhooks
- OpenAPI
- MuleSoft
- Boomi
- Azure Logic Apps
- Apache Camel
- RabbitMQ
- Identity and access
- OAuth 2.0
- OpenID Connect
- SAML 2.0
- SCIM
- Keycloak
- Microsoft Entra ID
- Healthcare standards
- HL7 v2
- HL7 FHIR
Ways to work with us
- Project-based deliveryXSIS delivers an agreed scope against written acceptance criteria, with a named delivery lead.
- Dedicated teamA complete team that works only on your product, run day to day by XSIS and directed by you.
- Staff augmentationEngineers and specialists who join your team, work in your tools and report to your managers.
Questions and answers
Should we use an integration platform or custom code?
It depends on how many connections you have and who will run them. An integration platform such as MuleSoft, Boomi or Azure Logic Apps gives you ready connectors, mapping and monitoring in one place, at a licence cost. Custom services give you full control and no licence, but you maintain more code. We compare both for your case and build on a platform you already own.
Link to this questionWhat happens when a partner’s API is down?
Requests that fail for temporary reasons are retried with increasing delays. Every write carries an idempotency key, so a retry never creates a second order or invoice. If a message still fails, it goes to a dead-letter queue with the payload and the error, an alert reaches your team, and it can be replayed once the partner recovers.
Link to this questionHow do you handle API version changes?
For the APIs you publish, we version them, keep old versions running for an agreed period and tell consumers what changes. For the APIs you call, we track each partner’s deprecation notices, test new versions in their sandbox and move before the old version is switched off. Contract tests catch an unannounced change before it reaches production.
Link to this questionCan you connect our identity provider?
Yes. We add single sign-on with OpenID Connect or SAML 2.0 through providers such as Microsoft Entra ID or Keycloak, and provision users automatically with SCIM where the application supports it. Services call each other with OAuth 2.0 tokens scoped to what each needs. Your identity provider stays the single place where access is granted and removed.
Link to this questionHow do you deal with rate limits?
We read each partner’s published limits and design around them: batching requests where the API allows it, caching data that rarely changes, spreading scheduled jobs and backing off when the partner signals that a limit is near. Monitoring shows how close each flow runs to its limit, so growth does not turn into failures.
Link to this questionHow long does it take to integrate a third-party service?
It depends on the quality of the partner’s API and documentation, whether it has a usable test environment, how quickly accounts and keys are issued, and how complex your data mapping is. Partner approval steps can set the pace. We give you a plan per partner after the inventory and start with the connection that removes the most manual work.
Link to this questionWhat drives the cost?
The number of partners and flows, the quality of their APIs, the mapping and business rules, volume and timing needs, and any integration-platform licences. Identity work and certification with a partner add effort. We estimate per connection after the inventory, so you can choose the order and see the cost of each.
Link to this questionWho owns the code and the work you produce?
Intellectual property in the work we build for you is yours from the first commit — no assignment step at the end. That covers the custom code, documentation and other deliverables made for you. Anything we bring that existed before, such as internal tools or libraries, stays ours, and you receive a licence to use it in your systems. Open-source components keep their own licences, and we list them for you.
Link to this questionTell us what you need to build or connect.
Describe the systems, the timeline and the constraints. The right engineers take it from there.
- Our team will call you within 24 hours during your preferred time slot
- Our team is available 24/7