AS/400 API Integration: A Practical Guide for Manufacturers

A few manufacturers we have worked with described the problem in almost the same way before their integration projects began:

"The inventory is correct in the AS/400, but our website still tells customers an item is out of stock."

"Every time we add a system, someone writes another custom program. Now only one person understands how half of them work."

"My team exports files overnight and spends the first hour of every morning reconciling the numbers."

"The data is all there. We just cannot get it out quickly enough for the rest of the business to use."

These are not signs of a failing AS/400. In most cases, the core platform is still doing exactly what it was built to do: running production, inventory, billing, shipping, and order processing reliably.

The difficulty begins when that information needs to move beyond the system.

A Manufacturing Execution System needs current work-order and production data. A supplier portal needs shipment information. Dealer and e-commerce channels need accurate finished-goods inventory. Analytics platforms need operational data from the plant floor.

The information already exists inside the AS/400. The problem is that accessing it may still depend on nightly batch jobs, file transfers, one-off programs, and developers who understand decades of RPG or COBOL log.

API integration closes that gap without requiring manufacturers to replace the core system. A controlled layer of reusable APIs can make trusted AS/400 functions available to modern applications while keeping the established business rules inside RPG, COBOL, and DB2.

This guide explains how that approach works, which integration patterns fit different business needs, and how manufacturers can begin with a focused use case without putting production stability at risk.

What AS/400 API Integration Means

API integration creates a controlled access layer around the AS/400 so modern applications can use the data and business logic already inside it.

It does not require manufacturers to replace the AS/400, rewrite every application, or move all workloads to the cloud.

In most manufacturing environments, the system already manages important functions such as:

• Inventory availability
• Bills of material
• Material requirements planning
• Work orders
• Pricing
• Order processing
• Shipment validation
• Invoice processing
• Customer-specific rules
• Approval workflows

The challenge is that modern applications should not need to understand RPG, COBOL, green screens, or internal DB2 table structures to use those functions.

An API layer makes selected business capabilities available as reusable services. These may include checking inventory, retrieving work-order status, reporting production completion, calculating prices, tracking shipments, or validating suppliers.

The AS/400 continues to execute the established business rules. The API provides a secure and documented way for other systems to request information or submit transactions.

Common AS/400 Integration Problems We See in Manufacturing

Across the manufacturing environments we have supported, the AS/400 itself was usually not the problem. It continued to manage production, inventory, pricing, orders, shipping, and finance reliably.

The difficulty appeared when clients needed that information to move between the AS/400 and modern applications.

Operational Data Is Not Available in Real Time

In many environments, the AS/400 contains accurate information about inventory, materials, work orders, pricing, shipments, and invoices. However, connected applications cannot access it when they need it.

Manufacturers may still depend on:

• Nightly batch files
• FTP transfers
• Manual inventory checks
• Spreadsheet reconciliation
• Morning validation routines

We saw this with a Tier-1 automotive supplier whose AS/400 managed inventory, bills of material, and work orders while a modern MES tracked activity on the production floor.

Because the systems were not exchanging information quickly enough, inventory records fell behind actual production and low material levels could not trigger replenishment requests in time.

These delays affect production planning, sales, customer service, and confidence in the information being used.

Integrations Depend on Batch Files and Manual Transfers

Many manufacturers have connected newer applications to the AS/400 through scheduled file transfers rather than real-time integration.

Data may be exported at the end of the day, transferred through FTP, imported into another system, and then manually reviewed for errors.

This creates a gap between what has happened operationally and what other systems display.

A completed production order may not update inventory until the next transfer. A shipment may leave the plant before the supplier portal reflects its status. A pricing or order change may take hours to reach an e-commerce or customer service application.

The integration works, but the delay reduces its business value.

Every Application Connects to the AS/400 Differently

Another issue we frequently encounter is that each integration has been developed separately.

One RPG or CL program may connect the AS/400 to the MES. Another may support EDI. Additional programs may exchange information with Salesforce, Shopify, warehouse systems, finance applications, or reporting platforms.

These connections may use different:

• Data formats
• Business rules
• Scheduling processes
• Error-handling methods
• Security controls
• Monitoring approaches

Documentation is often limited, and testing a change can be difficult because every connection behaves differently.

As the number of applications grows, maintaining these point-to-point integrations becomes increasingly complex and risky.

Modern Applications Cannot Reuse Existing Business Logic

Important business rules already exist inside many AS/400 environments. These may include pricing calculations, inventory allocation, bills of material, credit checks, order validation, and shipment processing.

The problem is that modern applications cannot easily call those routines.

Teams may therefore recreate the same logic inside the MES, CRM, portal, or e-commerce platform. Over time, the rules inside those applications can become inconsistent with the rules inside the AS/400.

This can result in two systems calculating different prices, displaying different inventory availability, or applying different order rules to the same process.

Suppliers and Customers Have Limited Visibility

Order, inventory, invoice, and shipment information may be accurate inside the AS/400, but suppliers and customers often cannot access it directly.

They must call or email internal employees for routine updates.

Internal teams then spend time checking the AS/400 and relaying information manually. Customers wait for answers, suppliers lack visibility, and service teams handle requests that could be resolved through a connected portal.

The issue is not missing data. It is that the data remains inaccessible through the channels where partners need it.

Any of these challenges feel familiar?

In 30 minutes, we will help you identify which integration issue to address first.

Schedule a Call

How to Choose the Right AS/400 Integration Pattern

Once the integration challenges are clear, teams can begin identifying the appropriate API approach.

API integration can take different forms depending on the business process involved. An inventory lookup, a production event, a supplier portal request, and a financial posting do not carry the same requirements or risks.

The right pattern depends on how quickly information must move, whether the AS/400 is being read or updated, and what should happen if a transaction cannot be completed.

Decide How the Information Should Travel

Some interactions follow a request-and-response pattern.

A system asks the AS/400 for the available stock of a part, the price of an item, or the status of an order and waits for an immediate answer.

REST APIs are generally well suited to these interactions because the requesting application needs a response before it can continue.

Other interactions are events that need to be recorded as soon as they happen.

Examples include:

• A production unit is completed
• A feeder bin reaches its minimum level
• Scrap is posted
• A cycle count is adjusted
• A shipment is confirmed

These events should not wait for the next scheduled file transfer.

They are better handled through event-driven messaging, often using IBM MQ, so they can be delivered reliably without requiring both systems to be available at exactly the same moment.

A system asking for information is different from a system reporting that something has happened. The integration pattern should reflect that difference.

Decide How the Systems Should Be Connected

The second decision concerns the overall integration architecture.

In many manufacturing environments, each application has been connected to the AS/400 separately over time. The MES may use one custom program, the CRM another, and the supplier portal a third.

Each connection may have its own data format, business rules, scheduling process, and error-handling method.

This point-to-point approach becomes harder to manage as more systems are added.

In a fully connected environment, the potential number of links follows the formula n(n-1)/2. Five systems can require up to 10 links, 10 systems up to 45, and 20 systems up to 190.

Not every environment will contain every possible connection, but the problem remains. Each new application can introduce another interface that must be developed, documented, secured, tested, monitored, and maintained.

A reusable API layer provides a more sustainable alternative.

The MES, CRM, portal, e-commerce platform, and finance system can access the same documented AS/400 services instead of relying on separate custom links.

Point-to-point integration becomes more fragile as the environment grows. A reusable service layer becomes more valuable because each new application can use capabilities that already exist.

Match the Integration Method to the Business Process

There is no single integration pattern that fits every process. Most interactions fall into three broad categories.

Use REST APIs for Real-Time Data Lookups

When an application only needs to retrieve information, a request-response REST API is often appropriate.

Examples include:

• Checking inventory availability
• Retrieving an invoice
• Looking up an order
• Calculating a price
• Checking shipment status
• Retrieving a bill of material

The requesting application sends a request, the AS/400 processes the relevant business logic, and the API returns the answer.

Use Event-Driven Messaging for Critical Transactions

Transactions that change the AS/400 system of record require stronger reliability controls.

Examples include:

• Material deductions
• Cycle-count adjustments
• Production completions
• Order updates
• Financial postings
• Inventory transfers

These transactions must not be lost or processed twice.

Event-driven messaging provides delivery, retry, queuing, and duplicate-handling controls. If one system is temporarily unavailable, the message can remain in the queue until processing resumes.

IBM MQ is commonly used in these situations because persistent messages can be retained until they are successfully processed. It can also support transactional coordination between message handling and database updates.

Use an API Gateway for External Access

When suppliers, customers, dealers, or partners need access, the underlying AS/400 services should sit behind an API gateway.

The gateway manages:

• Authentication
• Authorization
• Token validation
• Request filtering
• Rate limiting
• Logging
• Monitoring
• Traffic control

This prevents external applications from connecting directly to the AS/400 and provides a controlled entry point for outside access.

Expose Business Functions, Not Database Tables

Regardless of the integration method, APIs should represent business functions rather than raw database structures.

A strong API should:

• Validate an order
• Allocate inventory
• Calculate a customer price
• Confirm production completion
• Return shipment status
• Retrieve an invoice balance

It should not allow an outside application to update AS/400 tables directly.

Business rules may exist inside programs, validations, workflows, and exception-handling routines that are not visible from the database alone. Exposing raw tables can bypass those controls and allow connected systems to recreate the rules differently.

Questions to Answer Before Building an Integration

Each interaction should be evaluated against a consistent set of questions before development begins.

How Quickly Must the Information Move?

Does the data need to move immediately, or is a short delay acceptable?

This determines whether the process needs a synchronous API, asynchronous messaging, or a scheduled transfer.

Is the Interaction Read-Only or Transactional?

A stock lookup can usually be retried safely.

A material deduction, inventory adjustment, order update, or financial posting requires stronger controls because it changes the system of record.

Does the Request Need an Immediate Answer?

Some systems cannot continue until the AS/400 responds.

Others can submit a message and allow the transaction to be processed shortly afterward.

What Happens If Processing Fails?

Can the request be retried safely?

Could a duplicate create an incorrect inventory movement, order, shipment, or financial posting?

How will failed messages be identified and replayed?

What Traffic Levels Must the Integration Handle?

Is demand predictable, or could production events, e-commerce activity, or partner requests produce sudden spikes?

Queues, gateways, and rate limits may be required to protect the AS/400 from unpredictable traffic.

Does the API Reuse Existing Business Logic?

The API should call trusted AS/400 logic wherever possible.

Allowing external systems to bypass that logic can result in inconsistent pricing, validation, allocation, or approval rules.

Is the Service Internal or External?

External access requires stronger authentication, authorization, logging, traffic control, and monitoring than an internal application connection.

Can the Service Be Reused?

When several applications need inventory, pricing, order, invoice, or shipment information, the service should be developed once and reused rather than rebuilt for each connection.

How Will the Integration Be Monitored?

Manufacturers need visibility into:

• Failed API requests
• Delayed messages
• Duplicate transactions
• Slow response times
• Traffic spikes
• Authentication failures
• Unusual usage patterns

A Six-Step AS/400 API Integration Framework

Here is a six-step framework manufacturers can use to begin planning and implementing AS/400 API integration.

Step 1: Identify the First High-Value APIs

Do not begin by documenting every program, table, and workflow in the AS/400 environment.

Start with three to five business interactions that currently create delays, manual work, support dependency, or integration risk.

Strong starting points may include:

• Inventory availability
• Work-order status
• Production reporting
• BOM lookup
• Order status
• Price calculation
• Shipment tracking
• Supplier validation
• Invoice lookup
• Material-lot traceability

The first APIs should be small enough to deliver quickly and important enough to produce measurable value.

Step 2: Choose the Right API Enablement Technology

The technology used to expose AS/400 functions should match the complexity of the environment, available skills, and long-term support requirements.

IBM Integrated Web Services

IBM Integrated Web Services can expose selected AS/400 programs as services.

It may suit straightforward requirements and teams that prefer built-in IBM capabilities. More advanced authentication, orchestration, or lifecycle management may require additional tools.

Open-Source IBM i Tools

Tools such as HTTPAPI and YAJL can provide flexibility for organizations with strong RPG expertise.

They offer greater control, but the internal team remains responsible for support, maintenance, performance, security, and documentation.

Commercial IBM i Connectors

Commercial connectors designed for IBM i can accelerate API development and may include monitoring, support, security, and event-handling capabilities.

They can be useful when RPG skills are limited or enterprise vendor support is required.

API Management Platforms

Platforms such as IBM API Connect, AWS API Gateway, MuleSoft, Apigee, and Kong can manage:

• Authentication
• Rate limits
• Logging
• Monitoring
• API policies
• Versioning
• Traffic control

These platforms are often appropriate when the organization already uses enterprise API management tools.

Database API Generators

Database-based API generators can expose simple data lookups quickly.

However, they may not be appropriate when the API must apply pricing rules, validations, approvals, workflows, or other business logic contained within AS/400 programs.

Step 3: Place an API Gateway in Front of the AS/400

The API gateway should act as the control point between modern applications and the AS/400 environment.

A typical request flow is:

Application or external system → API gateway → service layer → AS/400

The gateway manages access, filtering, traffic, and monitoring. The service layer applies the required business rules before the request reaches the core system.

This prevents the AS/400 from handling every invalid request, external access attempt, or traffic spike directly.

Step 4: Build APIs Around Business Capabilities

Each API should represent a clear business action or answer.

Examples include:

• Check inventory availability
• Calculate a customer price
• Validate a work order
• Confirm production completion
• Retrieve shipment status
• Return an invoice balance

The design should reuse established AS/400 business logic rather than bypassing it.

Step 5: Put the First API into Production

The first API should support a real business process.

It should be:

• Secured
• Documented
• Tested
• Monitored
• Released into production
• Assigned to a clear owner

Once it is live, measure:

• Response time
• Error rate
• Call volume
• Manual work reduced
• Delays removed
• Support tickets avoided
• User adoption

These measures turn the initiative into a business case rather than a purely technical exercise.

Step 6: Establish a Repeatable API Delivery Model

One API can be built through individual effort. A wider integration program requires standards.

Create repeatable practices for:

• API design
• Security
• Documentation
• Testing
• Deployment
• Monitoring
• Ownership
• Versioning
• Retirement

This is also an opportunity to align IBM i development with modern engineering practices through Git, Code for IBM i, automated testing, CI/CD, and release governance.

Experienced AS/400 developers should help document important business rules while their knowledge is still available. AI-assisted documentation may help accelerate the work, but experienced developers should review and validate the output.

Start With a 30-Minute Conversation

Most teams already know which process is costing them. The harder part is knowing what to do about it, and that is usually a short conversation, not a big project. Give us 30 minutes. We will look at your setup, show you where API integration would remove the most manual work, and tell you what it would realistically take. Book a 30-minute consultation and we will help you find the fastest, lowest-risk place to start.

Frequently Asked Questions About AS/400 API Integration

Can an AS/400 Be Integrated with an MES Without Replacing the ERP?

Yes. REST APIs and event-driven messaging can expose selected inventory, work-order, BOM, and production functions from the AS/400.

The MES can exchange information with the system in real time while the core ERP continues to operate.

How Does API Integration Support Supplier EDI?

APIs can make order status, shipment tracking, inventory availability, and invoice information available through a managed gateway.

Supplier and EDI systems can use secured and documented services instead of relying only on nightly files or separate custom programs.

Is It Safe to Expose the AS/400 Through APIs?

It can be safe when the architecture includes an API gateway, authentication, authorization, request validation, rate limiting, logging, monitoring, and controlled service access.

External applications should not connect directly to internal database tables or unrestricted core programs.

How Quickly Can a Manufacturer See Value?

Many organizations begin with three to five high-value APIs.

Value can appear once the first production API removes manual reconciliation, reduces support calls, or gives plant teams access to current operational information.

What Types of Savings Can API Integration Create?

Potential savings may come from:

• Reduced manual work
• Lower integration maintenance
• Fewer one-off custom programs
• Faster access to operational data
• Reduced support dependency
• Improved employee productivity
• Fewer reconciliation errors

Any percentage or financial estimate should be evaluated against the manufacturer's current environment and supported by verified data.