Manufacturing API Integration: RFP and Acceptance for ERP, MES and WMS

Manufacturing API integration development should procure more than endpoints. It should establish a business-transaction contract that prevents duplicate posting, supports recovery after failure, and leaves auditable evidence across ERP, MES, WMS, QMS, and labeling or shipping systems. This guide gives factory management, manufacturing, IT, procurement, and implementation teams in Thailand and ASEAN a practical path from RFP through a 90-day PoC, FAT/SAT, and operational handover.

Why “an API exists” does not mean the integration is operationally safe

A vendor may truthfully answer that its product has a standard API, yet that answer says little about production readiness. Receiving HTTP 200 or 202 is not the same as proving that inventory movement, production completion, inspection disposition, or shipment confirmation was correctly posted. Processing may fail after receipt, only some lines may succeed, or a response may disappear after the destination has committed the transaction.

Consider an MES sending a production completion to ERP. ERP posts it, but the response times out. If MES retries and ERP creates a second completion, inventory, costing, and genealogy diverge. If MES does not retry, the systems may still disagree. The contract must therefore define how both sides identify the same business intent, what happens on a duplicate, how the original result is retrieved, and how the final records are reconciled.

IETF RFC 9110 defines idempotent semantics for PUT, DELETE, and safe HTTP methods, and cautions clients about automatically retrying non-idempotent requests. That transport semantics does not guarantee end-to-end business idempotency. A production-completion POST, material issue, or shipment confirmation still needs a stable business key, deduplication rule, result lookup, and reconciliation.

Seven deliverables to put in the RFP

1. Transaction inventory and source-of-truth matrix
2. Data contract covering schema, codes, units, time, and precision
3. Business-key and idempotency or deduplication rules
4. Timeout, bounded-retry, exception-queue, and manual-replay rules
5. Correlation IDs, logs, dashboards, and periodic reconciliation
6. Version, compatibility-window, deprecation, and rollback policy
7. Reproducible acceptance evidence for normal and fault-injection tests

Without these items, a low development quote can merely shift cost into incident investigation, duplicate correction, and person-dependent replay. A factory does not need to replace every system at once; it can formalize one transaction boundary at a time. Use the broader business-system and ERP integration guide to frame the program, then apply this article’s contract to each interface.

Establish source of truth and transaction ownership across ERP, MES, WMS and QMS

Choose the business fact, its owner, and its completion condition before choosing REST, events, or files. Source of truth is not necessarily the system that first creates a record. It is the system authorized to change and finalize that fact, including its correction and audit process.

Replace the examples with site-specific decisions. Both ends must agree on what “success” means. Do not collapse transport receipt, syntax validation, business validation, posting, and downstream completion into one success code.

Separate transport success from business acceptance

The contract should expose at least two states:

• Transport success: the API boundary received and structurally validated the request.
• Business acceptance: the order, stock, completion, or disposition passed business rules and was posted to the system of record.

For asynchronous processing, return a correlation or processing ID and provide final-state lookup. Errors should map to action: retryable, data correction required, master-data missing, awaiting approval, or already processed. “Error” alone is not operable.

Remove ownerless gaps with a responsibility matrix

Assign a business owner, source technical owner, destination technical owner, data owner, and replay approver to every transaction. The API gateway team cannot be the sole owner. A gateway can observe traffic but cannot decide whether a production completion or quality release is valid. Define responsibility by role and duty roster so it survives staff changes; keep personal contacts in the runbook.

A data contract describes meaning, not only a JSON example

A sample payload does not control the variability of production data. Microsoft Azure Architecture Center’s API-design guidance recommends modeling the business domain rather than exposing internal database structures. This is useful vendor-neutral architectural guidance, not a requirement to purchase Azure.

Thailand’s ETDA Recommendation 27-2564 describes core components, business information entities, and data types for consistent electronic-message design. It can inform shared definitions in Thailand; it is not a mandatory certification for each factory API.

Assign responsibility for codes and units

“EA” versus “PCS,” “KG” versus “kg,” local time versus UTC, and production date versus accounting date can create a correct connection with an incorrect business result. Decide whether the sender, receiver, or a governed shared service converts each value. Unknown codes should normally be held in an exception queue or resolved through an approved mapping, not silently created.

Validate schemas at the boundary

NIST SP 800-228 Update 1 organizes cloud-native API protection across pre-runtime and runtime stages, including inventory, schema validation, authentication, authorization, monitoring, and throttling. It is not a manufacturing regulation. It is nevertheless a useful lifecycle checklist: reject invalid input before it reaches deep business processing, and retain a correlation ID and safe reason code.

API idempotency, bounded retries, duplicates and late messages

Idempotency is more than ignoring a duplicate. Repeating the same intent must not create additional side effects, and the caller must be able to retrieve the original outcome. AWS Builders’ Library discusses client request identifiers and late-arriving requests as patterns for safe retries. AWS is not mandatory; the design problem applies to any platform.

Keep the business key separate from the correlation ID

A correlation ID supports tracing. A business idempotency key supports deduplication. A new correlation ID created for every retry cannot identify the same production completion. The sender should generate a stable key such as plant + order + operation + completion sequence, and the receiver must persist it.

When the receiver sees the same key, the contract should specify:

• Same key and same content: return the original result ID and state.
• Same key and different content: reject as a conflict; do not overwrite.
• Original request still processing: return processing state and a result lookup.
• Original result beyond retention: follow the retention and reconciliation procedure.

Without these rules, every network timeout becomes a human decision about whether it is safe to press a button again.

Bound retries and use backoff with jitter

Retry only transient conditions such as a short timeout, throttling, or temporary dependency outage. Authentication failure, schema violation, unknown master data, and a business conflict will not heal if identical data is resent. Specify maximum attempts, total duration, increasing wait, randomized jitter, and the destination after the limit. The AWS Architecture Blog article on exponential backoff and jitter explains how to avoid synchronized retry storms; it does not justify infinite retries. Always combine bounded retries with idempotency.

Test delay, reordering and partial success

Define what happens when cancellation arrives before completion, only some inventory lines are accepted, or label printing succeeds while shipment confirmation fails. Validate prerequisite state rather than relying only on a sequence number. Decide whether an out-of-order message waits, fails, or enters quarantine. Transactions that cannot tolerate partial success should be atomic. If partial success is allowed, return line-level results and an explicit replay unit.

Exception queues, replay authority, correlation IDs and reconciliation

Do not discard a request when retries expire, and do not manage it by copying payloads into email. An exception record should contain the business key, correlation ID, source, transaction, occurrence time, latest error, attempt history, current owner, next action, and evidence link. Protect raw requests and responses in an access-controlled store; mask secrets and personal data.

Separate duties for manual replay

Replay is a state-changing operation that can create a duplicate. Separate viewing, data correction, replay approval, and execution. Record who changed which data, why, and how the resulting business state was checked. The required approval depth should follow the site’s risk, but authority must be explicit.

Before replay, query the destination using the business key. Never infer “not processed” from a missing response. If already posted, recover the original result; if not, retry with the same idempotency key.

Preserve correlation across every hop

ERP, gateway, MES/WMS/QMS, monitoring, and the exception queue should all be searchable by the same correlation ID. Do not use that ID alone to establish business identity. Dashboards should separate received, processing, accepted, business rejected, technically failed, and queued items. Look beyond averages to long-lived exceptions and clusters around a particular master or transaction.

Reconciliation is the final safety net

Green message monitoring does not prove aligned business records. At an appropriate interval, compare source orders, completions, movements, dispositions, and shipments with destination postings by business key. Reconcile quantities, lots, state, and revision—not just counts. Send differences back to the exception process and assign an owner, resolution time, and escalation path.

API gateway and security controls—and the gateway’s limits

An API gateway can centralize routing, authentication, mTLS termination, rate limiting, logging, and monitoring. Microsoft Azure Architecture Center’s gateway guidance is a useful description of those functions and is not limited conceptually to Azure.

A gateway cannot determine:

• whether two completions represent the same business transaction;
• whether ERP or WMS owns a stock state;
• who may approve a quality disposition change;
• whether business posting finished after an HTTP success;
• how to correct a duplicate shipment; or
• who resolves a reconciliation difference.

It is valuable traffic control and boundary protection, but not a substitute for business ownership and reconciliation.

Minimum security questions for the RFP

Use NIST’s lifecycle view and OWASP API Security Top 10 — 2023 to examine authorization, resource consumption, inventory, and unsafe consumption of external APIs. OWASP is an expert-consensus awareness checklist; it does not quantify the risk of an individual factory.

• Inventory of APIs, consumers, owners, environments, and versions
• Object- and function-level authorization
• Service authentication, short-lived credentials, secret storage and rotation
• Schema, size, rate, concurrency, and query-scope controls
• Validation of external API responses as untrusted input
• Tamper-resistant, masked, access-controlled logging and retention
• Vulnerability response, approved change, emergency disablement, and recovery

Never place passwords or API secrets in article examples, diagrams, or acceptance evidence. Separate test credentials from production and verify that logs, screenshots, and exported files do not expose them.

Versioning, compatibility windows, consumer inventory and rollback

Factory systems often cannot stop and upgrade simultaneously. The contract must state how long the old version remains available, which consumers still use it, and how to recover—not simply that everyone must use the latest version.

Classify changes as:

1. Compatible: for example, adding an optional field without breaking existing consumers.
2. Conditionally compatible: code or length changes whose effect depends on consumer implementation.
3. Breaking: changes to required fields, meaning, unit, key, or processing order.

Even an added field can break a strict deserializer, screen, report, or downstream file. Regression-test the full consumer path. Maintain a consumer inventory with API, version, plant, system, owner, transaction, last use, and migration plan.

The RFP should state notification channel, compatibility window, migration environment, test data, shutdown criteria, and extension authority. Rollback is not only redeploying an old application. Verify whether the old version can read data written by the new one and whether the deduplication ledger and queues remain usable. Record the cutover key range so both versions cannot process the same transaction.

API integration RFP: compare vendors through deliverables and evidence

Combine the system-development contracting guide with an API-specific acceptance appendix. Compare who produces each artifact and what evidence proves completion, not only product features.

Make quotations comparable by separating interface/data-contract design, implementation, gateway/security/observability, test harness and data, cutover/training/runbook, and recurring runtime, monitoring, and regression testing. Ask vendors to explain how they reproduce duplicate requests, timeout, reordering, partial success, schema drift, token expiry, rate limiting, dependency outage, and rollback. Require procedure, expected result, captured log, and accountable role—not “supported.” The manufacturing system-integrator selection guide helps extend this assessment to shop-floor handover capability.

API acceptance testing: FAT, SAT and a 90-day PoC

Acceptance is not a demonstration in which one normal record passes. Tests must be repeatable and must produce the expected business state, log, alert, queue record, and reconciliation result. FAT validates the contract and fault behavior in a controlled environment. SAT validates site-specific networks, identities, masters, and operating responsibility under production-like conditions.

The PoC should not maximize feature count. It should prove, on representative transactions, that a failure can be detected, contained, recovered, and reconciled safely.

Normal and fault-injection checklist

• A normal request posts once.
• Same key and content returns the original outcome without extra side effects.
• Same key with different content is rejected as a conflict.
• A retry after a lost response returns the original outcome.
• Delayed and out-of-order messages follow the agreed wait, reject, or quarantine rule.
• Partial success returns line outcomes and an explicit replay unit.
• Schema drift and unknown codes are isolated.
• Token expiry fails without exposing a secret.
• Rate limiting uses bounded retry without a retry storm.
• Dependency outage aligns the queue, alert, and dashboard.
• Manual replay requires approval and produces an audit trail.
• Rollback prevents both versions from processing the same transaction.
• Source and destination records trace through business key and correlation ID.
• Reconciliation detects an intentionally planted difference.

The evidence pack should contain test case, prerequisite data, execution time, input, expected and actual result, log query, output capture, defect ID, retest result, and approver. Remove secrets and personal data from raw messages. Good evidence is not merely a large volume of logs; it can explain one business transaction from source to final posting.

Illustrative five-interface, five-million-message model

All figures below are explicit TOMAS TECH assumptions for planning dialogue. They are not market averages, quotations, customer results, or guaranteed savings. Replace them with actual message counts, exception logs, loaded labor, incident costs, and infrastructure quotations.

The model covers five interfaces: ERP→MES production orders, MES→ERP completions, ERP↔WMS inventory movements, QMS→ERP inspection disposition, and ERP/WMS→label and shipping confirmation.

Message and exception assumptions

• 20,000 business messages/day × 250 operating days/year = 5,000,000 messages/year.
• Baseline exception rate 0.30% = 15,000 exceptions/year.
• Improved exception rate 0.05% = 2,500 exceptions/year.
• Handling time 8 minutes/exception.
• Baseline: 120,000 minutes = 2,000 hours/year.
• Improved: 20,000 minutes = 333.3 hours/year.
• Loaded labor: 900 THB/hour.
• Baseline exception labor: 1,800,000 THB/year.
• Improved exception labor: 300,000 THB/year.
• Illustrative reduction: 1,500,000 THB/year.

Additional avoided losses are assumptions too: 12 duplicate production/shipment correction incidents/year × 60,000 THB = 720,000 THB/year, plus 10 equivalent interface-outage hours/year × 60,000 THB = 600,000 THB/year.

Gross illustrative annual value is 1,500,000 + 720,000 + 600,000 = 2,820,000 THB. Subtracting 420,000 THB annual operation gives 2,400,000 THB net/year. Simple payback is 2,800,000 ÷ 2,400,000 = 1.17 years.

At 50% realization, 2,820,000 × 50% − 420,000 = 990,000 THB net/year, and payback is 2,800,000 ÷ 990,000 = 2.83 years. Showing the sensitivity prevents the base case from being mistaken for a promise.

Replace the assumptions in this order: count real business transactions; classify technical, data, and business exceptions; measure handling time and loaded labor; agree actual duplicate, outage, and shipping correction cost; obtain implementation and runtime quotations; then compare base, conservative, and adverse cases. The industrial data-fabric guide covers the broader contextual-data architecture; this model stays limited to failure and recovery for five API transactions.

Frequently asked questions

Should ERP–MES API integration use REST or events?

Start with the transaction. REST may fit immediate queries and clear request-response work; events may fit loose coupling and multiple consumers; files may remain practical for existing equipment and batches. Every option still needs source of truth, business keys, ordering, duplicates, result lookup, reconciliation, and ownership.

What should a WMS API integration define first?

Define warehouse, location, item, lot, stock status, quantity, unit, movement reason, document key, and line key. State whether ERP or WMS owns physical location, allocation, and accounting quantity in each state. Test partial receipt, cancellation, stocktake differences, and delayed arrival.

Is an endpoint list sufficient for an API integration RFP?

No. Require ownership, source of truth, completion condition, data contract, idempotency, bounded retry, exception queue, replay authority, correlation, reconciliation, version policy, rollback, and FAT/SAT evidence. Specify peak load, payload, acceptable latency, and backlog recovery—not only average volume.

Which API acceptance test reveals the most?

Test “the destination committed, but the response was lost.” Retry the same business key and verify that no duplicate is created and the original result is returned. This exercises idempotency, result lookup, logs, and reconciliation together. Also inject reordering, partial success, schema drift, token expiry, rate limiting, dependency outage, and rollback.

Does using PUT guarantee API idempotency?

No. HTTP method semantics and the business side effect must be designed separately. Production completion, material issue, and shipment confirmation require a stable key, deduplication record, conflict behavior, original-result retrieval, retention, and reconciliation.

Does an API gateway solve exception operations?

No. It can centralize routing, authentication, limits, and logging. Manufacturing, quality, and logistics owners must still decide source of truth, data correction, replay approval, and reconciliation.

Summary

Manufacturing integration proves its quality after a duplicate, delay, partial success, dependency outage, or version change—not when the first happy-path message passes. Put transaction ownership, semantic data contracts, business idempotency, bounded retries, exception and replay controls, end-to-end correlation and reconciliation, compatibility and rollback, and fault-injection FAT/SAT evidence into one acceptance contract. An API is operationally ready only when the plant team can explain and recover a failed business transaction without creating another one.

If you are deciding which ERP, MES, WMS, or QMS transaction should enter a PoC first—or converting an existing interface specification into a procurable RFP—contact TOMAS TECH. We can help structure the 90-day scope and evidence using your real messages, exception history, and operating model.

References

1. NIST, *SP 800-228 Update 1: Guidelines for API Protection for Cloud-Native Systems*

https://csrc.nist.gov/pubs/sp/800/228/upd1/final

1. IETF, *RFC 9110: HTTP Semantics*

https://datatracker.ietf.org/doc/html/rfc9110

1. AWS Builders’ Library, *Making retries safe with idempotent APIs*

https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/

1. AWS Architecture Blog, *Exponential Backoff and Jitter*

https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/

1. Microsoft Azure Architecture Center, *API design*

https://learn.microsoft.com/en-us/azure/architecture/microservices/design/api-design

1. Microsoft Azure Architecture Center, *Use API gateways in microservices*

https://learn.microsoft.com/en-us/azure/architecture/microservices/design/gateway

1. OWASP, *API Security Top 10 — 2023*

https://api-security.owasp.org/editions/2023/en/0x00-header/

1. Thailand ETDA, *Recommendation 27-2564: Core Component Specification for Data Interoperability*

https://www.etda.or.th/getattachment/017b9ba7-fb0e-4648-922d-cb1117eeec3b/%E0%B8%82%E0%B8%A1%E0%B8%98%E0%B8%AD-27-2564.aspx

1. Thailand BOI, *1H 2026 investment announcement*

https://www.boi.go.th/un/boi_event_detail?language=en&module=news&topic_id=139075

The BOI announcement reports 132 applications totaling approximately 17.2 billion baht under Smart and Sustainable Industry in 1H 2026, covering machinery upgrades, digital technology, automation, and robotics. This is investment context, not a count of API projects and not proof that an individual API project automatically qualifies for incentives.