AS400 API Integration
Exposing existing RPG and COBOL program logic through APIs lets an AS400 or IBM i system connect to mobile apps, e-commerce platforms, and partner systems without rewriting decades of business logic. This is usually the highest-leverage modernization step an IBM i shop can take.
Most business value on an AS400 or IBM i system lives in program logic, not in the interface it happens to be attached to. API integration is the modernization category that unlocks that value for systems that did not exist when the original programs were written: mobile apps, e-commerce platforms, partner EDI connections, and internal microservices. It is frequently the highest-leverage modernization investment available, because it reuses tested logic instead of rebuilding it.
Why API Integration Matters
Before API integration, connecting an outside system to IBM i logic typically meant either duplicating business rules in the new system (creating two places where the same rule can drift out of sync) or building brittle, direct database access that bypasses application-level validation. Well-designed APIs solve both problems: they expose a defined, controlled interface to existing logic, so the AS400 system remains the single source of truth for the rules it already enforces.
Common Approaches to Exposing IBM i Logic as APIs
Two general approaches are common on IBM i. The first wraps existing RPG or COBOL programs directly, converting their inputs and outputs into a callable web service without rewriting the program's internal logic. The second builds new logic, often in RPG, Java, or another IBM i-supported language, specifically as an API layer that calls into existing programs or DB2 for i data as needed. IBM i's integrated database also supports SQL and HTTP-based access patterns that some integration projects use directly, depending on how much application-level logic needs to sit in front of the raw data.
Common Use Cases
The most common drivers for AS400 API integration projects are: mobile apps for field staff, warehouse operations, or customer self-service; e-commerce platforms that need real-time inventory, pricing, or order status from the core system; EDI and partner integrations replacing older batch file transfer methods; and internal automation connecting IBM i to other systems in the organization's software stack.
Design Considerations
API projects on IBM i tend to succeed or fail based on decisions made early: how authentication and authorization are handled, whether the API layer enforces its own validation or simply passes through to existing program logic, and how much of the existing program needs to be refactored versus wrapped as-is. Treating the first API project as a template, rather than a one-off, pays off quickly once a second and third integration need appears, which they typically do once the first project proves the approach works.