--- title: "Application and API integration" description: "API design, event streaming and middleware that connect ERP, CRM, finance, HR and custom applications, with every message monitored." url: https://www.expandware.com/services/integration/application-and-api-integration/ section: "Services" topics: ["Integration", "REST", "GraphQL", "OpenAPI", "AsyncAPI"] publisher: "Expandware Private Limited" --- # Application and API integration API design, event streaming and middleware that connect ERP, CRM, finance, HR and custom applications, with every message monitored. Every system talking to every other, through interfaces you can see. Point-to-point connections accumulate until nobody can say what breaks when one system changes. We replace them with an integration layer designed on purpose: APIs with versioned contracts, events for things that happen, and middleware only where it earns its place. Every interface has an owner, a retry policy and an alert, so a failed message is visible within minutes rather than at month end. Where it usually starts: - Data is re-keyed between systems, or moved by scheduled spreadsheet exports. - A change to one application breaks an integration nobody knew existed. - Failed messages are discovered by customers or by finance, not by monitoring. - A new SaaS platform has to connect to an estate that was never designed for it. What is included: - Integration architecture: A target design for how systems connect: APIs, events, batch and file transfer, each used where it fits. - API design and management: REST and GraphQL APIs with versioned contracts, authentication, rate limits and a developer portal where one is needed. - Event streaming: Kafka, cloud event buses and webhooks for things that happen, with ordering and replay designed in. - iPaaS and middleware: MuleSoft, Boomi, Azure Integration Services, AWS integration services, n8n and Power Automate, configured and governed. - Monitoring and alerting: End-to-end tracing of messages across systems, with dead letter handling and alerts that name the failed interface. - Interface catalog: A living register of every integration, its owner, its contract and its dependencies. Where it sits: This service builds the integration layer itself: the API gateway and event bus that sit between your CRM, HR and other systems of record and the portals that read from them, plus the monitoring and interface catalog that keep every connection owned once it is live. Decisions to settle early: - Platform or plain code. An iPaaS suits many standard connectors and a team that prefers configuration; hand-built services suit unusual logic and high volume. We recommend per interface, and most estates end up with both. - Events or requests. Requests suit questions that need an answer now; events suit facts other systems should learn about. Choosing well decides how much breaks when one system is down. - Who owns each interface. Ownership by the producing team, the consuming team or a central integration team each works, but mixing them silently does not. We agree the rule before building. How the work runs: Map, Every existing interface, including the undocumented ones. Design, Target integration architecture and contracts. Build, Integrations delivered in priority order behind tests. Operate, Monitoring, alerting and an owner per interface. How it is bought: - A fixed-fee assessment: We read your existing interfaces, schedules and failure logs, and map the estate as it really runs. You receive an interface inventory, the riskiest dependencies ranked, and a fixed price for the integration work that follows. - A fixed-price build: The agreed interfaces are designed, built and tested in priority order, behind contracts in your repository. The price covers the gateway, event streams and monitoring named in the scope, with every assumption written into the proposal. - Running it afterwards: Interfaces can be handed to your team with runbooks and alerting, or kept under our monthly operation, where we own failed deliveries, contract changes and the catalog against an agreed service level. Worked example, order data keyed in three times. Say a wholesale distributor takes orders in an e-commerce platform, re-keys them into its ERP and exports them nightly to a warehouse system. Errors surface when a customer calls about a missing delivery, and nobody can say which system holds the true order. - Map: We trace every movement of an order, including the nightly export a former employee scheduled and the spreadsheet finance uses to reconcile it. - Contract: An order event is defined once, with an owner and a version, and each system publishes or consumes it instead of copying fields by hand. - Build: Integrations are built behind tests in priority order, starting with the path from storefront to ERP, and run alongside the old process until the numbers agree. - Watch: Every message is traced end to end. A failed order lands in a dead letter queue and alerts the owner of that interface, not the whole team. At the end, an order is entered once, the catalog shows which systems touch it, and a failure reaches the person who can fix it before the customer notices. (An illustration, not a client account.) What you have at the end: - Interface catalog with owners and dependencies: Every integration listed with its owner, contract and the systems on either side, so a change can be assessed before it is made. - Integration architecture and contract specifications: The target design, and an OpenAPI or AsyncAPI contract for each interface, versioned alongside the code. - Tested integrations in your repository: Source, configuration and automated tests for every integration, in your version control rather than ours. - Monitoring dashboards and alert routing: Message flow, error rates and dead letter queues on dashboards, with alerts routed to the owner of each interface. - Runbooks for every failure mode: Step by step recovery for each way an interface can fail, from expired credentials to a replayed event. Standards and platforms worked with: REST, GraphQL, OpenAPI, AsyncAPI, Apache Kafka, MuleSoft, Boomi, Azure Integration Services, AWS EventBridge, OAuth 2.0. Where it goes wrong, and what we design out: - A layer nobody owns. Integration platforms decay when no single person answers for an interface. Every connection we build has a named owner, an alert that reaches them and an entry in the catalog before it carries production traffic. - Contracts that drift. When producers change payloads without telling consumers, failures surface weeks later. Versioned contracts and automated contract tests catch the change in the pipeline, before it is deployed. - Middleware for its own sake. An iPaaS licence is not an architecture. We use middleware where it removes work, and plain APIs or events where it would only add a hop to debug. What it changes: - Fewer manual handoffs. Data entered once flows to where it is needed, so staff stop re-keying and reconciling. - Failures found in minutes. Monitoring catches a failed message before it becomes a missing invoice or a lost order. - Upgrades without fear. Versioned contracts let a system be replaced or upgraded without breaking the ones around it. How you will know it is working: - Failed messages are seen by the interface owner before anyone downstream notices. - A proposed change to one system can be checked against everything that depends on it. - Nobody re-keys data that already exists in another system. - New applications connect through the layer instead of adding another point-to-point link. Who you work with: - Integration architect. Designs the target layer, the contracts and the ownership model, and reviews every interface before it goes live. - Integration engineers. Build, test and document the interfaces in your repository, and write the runbooks for each failure mode. - Operations engineer. Sets up tracing, dead letter handling and alerting, and runs the interfaces if we operate them for you. What we need from you: - Access to the systems being connected, in a test environment where one exists. - A named owner on your side for each business process the interfaces serve. - Any existing interface documentation, however out of date. - Time from the people who reconcile data by hand today. Common questions: Q: Should we buy an iPaaS or build middleware? A: It depends on how many systems there are, how often they change and who will maintain the integrations. An iPaaS earns its licence when there are many connectors to manage and a team to govern them; a small set of high volume integrations is often cheaper and clearer as code. We compare both on your numbers before recommending either. Q: Can you integrate with a system that has no API? A: Usually. Databases, file drops, message queues and, as a last resort, controlled screen automation can all be wrapped behind a proper interface, so the rest of the estate never deals with the legacy system directly. Q: How do you handle data that changes in two places? A: By deciding which system owns each field and synchronizing in one direction wherever possible. Where two systems genuinely both write, conflict rules are written down and enforced in the integration, not left to whichever update arrives last. Q: How do you secure integrations? A: Every connection authenticates with scoped credentials kept in a secrets manager, traffic is encrypted and access is reviewed. An integration account with administrator rights everywhere is one of the most common findings in the estates we inherit. Q: What is an interface catalog, and who keeps it current? A: A register of every integration: what it connects, who owns it, which contract it follows and what depends on it. We build it during mapping and hand it over with the integrations. Keeping it current becomes part of your change process, so a new interface is not live until its entry exists. Q: How do you version an API without breaking the systems that use it? A: Contracts change additively wherever possible: new fields are optional and old ones keep working. When a breaking change is unavoidable, the new version runs alongside the old one, consumers are told when the old one retires, and usage is monitored so nothing is switched off while it is still being called. Q: What happens to a message when the receiving system is down? A: It waits rather than disappearing. Retries follow a backoff policy, and a message that still cannot be delivered moves to a dead letter queue with the reason recorded. The owner is alerted, and the message can be replayed once the receiving system is back. Q: Can you work alongside our own integration team? A: Yes. Many engagements are a mix: your team owns some interfaces and we build or rescue others. We use your repositories, review process and tooling where they exist, and the catalog and runbooks are written so either team can operate any interface. Often paired with: Data integration and analytics, ERP and business systems, Identity and Zero Trust. --- Canonical page: https://www.expandware.com/services/integration/application-and-api-integration/ Site index for machines: https://www.expandware.com/llms.txt Full site text: https://www.expandware.com/llms-full.txt Expandware Private Limited. Inquiries: solutions@expandware.com, +92 (333) 32 11011.