Your ERP Has an API. Does It Cover the Workflow You Need?

"Yes, the ERP has an API" is one of the most reassuring sentences in an automation project, and one of the least informative. It tells you a door exists. It doesn't tell you whether the account your workflow will use can get through it, reach the fields you need, attach the artwork file, and leave behind an order your team can actually work from.

Most ERP integration articles stop at the door. This one is about what's behind it: a checklist you can run against one real transaction to find out which steps are covered, which need another route, and which should stay manual for now.

An ERP API covers your workflow only when the account the workflow uses can perform every required operation, keep each field's business meaning intact, and confirm the final record. Test reads, writes, attachments, approvals, custom fields, and recovery separately. A successful create response is not proof of a finished order.

Pick one transaction and list everything it touches

Choose a representative workflow, such as turning an approved customer PO into a draft sales order. List the information it needs and the actions it takes. For each item, record the source, the destination, the operation required, the permission involved, how you'll verify the result, and who handles it if the automated route fails. In a promotional-products business, that list usually includes:

• Customer and supplier identifiers, including company or subsidiary boundaries.
• Product variants, sizes, colors, quantities, and units of measure.
• Decoration method, imprint location, setup charges, and repeat-order references.
• Ship-to addresses, split shipments, freight charges, and in-hands dates.
• Custom fields, plus linked records such as opportunities, purchase orders, and production jobs.
• Attachments, approval state, and the next action your staff expect to take.

Treat read, create, update, and business actions as separate rows. An API may let your integration read a field without letting it change that field, and creating a draft can have different requirements from releasing or canceling the same record.

Check the schema of the account you'll actually use

Start with the vendor's current documentation, then inspect the live environment with the role the workflow will use. Editions, releases, customizations, enabled features, and permissions all change what's available, so a field list copied from someone else's implementation isn't evidence about yours.

Oracle's NetSuite documentation describes a REST metadata catalog that lists available records, their fields, sublists, and subrecords, both standard and custom, along with supported HTTP methods. New customizations appear in it, and it gives each user a personalized view. That makes inspecting the metadata a better starting point than a generic field list. See NetSuite's resource metadata documentation. NetSuite also publishes a list of records supported in REST web services, with notes on feature requirements. Use it to decide what to test, not as proof that every field or status change you need will work for your integration.

SAP Business One's Service Layer reference lists entities with their operations and actions, including an Attachments2 entity. So if someone tells you "Business One can't handle attachments," check the release, configuration, file location, operation, and permissions before treating that as a product-wide limit. See the SAP Business One Service Layer API reference.

Test what fields mean, not just what they're called

Two fields called "shipping cost" can hold different amounts. One might be the customer charge, another the vendor cost, and a third an estimate. Copying values between them can quietly distort margin reporting while every request returns a success code.

Ask the operations owner to define the business meaning, currency, tax treatment, and timing of each field that matters. Confirm whether a date is requested, promised, estimated, or actual. Decide what an empty value means: keep the existing value, clear it, or send the record for review.

Use test records with known expected results. After writing, read the record back and have an experienced user check the normal ERP screen or report, including totals and linked records. What you're really testing is whether the rest of the business can use the result without fixing it.

Sample acceptance rows for one PO

Take a made-up PO for 120 navy mugs with a one-color imprint, a separate setup charge, and an approved artwork file. Run it with test records whose correct values you already know.

Each row needs an owner, the evidence you observed, and a result. If artwork fails while everything else passes, the honest description is "draft created, awaiting artwork," with a named person to finish it and the order ID kept for the repair.

Label every gap

Mark each row as verified, supported but untested, unavailable through this route, or needing clarification. Keep those labels visible for the whole pilot rather than letting "untested" drift into "done."

For an operation the API doesn't cover, work through the supported alternatives with the application owner. That might be another documented interface, an approved import, a vendor extension, a browser step, or a manual handoff. Compare the maintenance and control each one adds before picking.

A workflow that creates a draft order through the API and sends the record link to a person for a specialized attachment step can be a complete, useful process when the handoff is deliberate. It becomes risky when the workflow reports the whole order as finished and nobody is told about the missing piece.

Put recovery in the acceptance test

Clean transactions are the easy part. Also test missing customer references, unfamiliar variants, invalid dates, duplicate incoming POs, revoked permissions, interrupted responses, and a record another employee edits while the run is in progress.

A timeout after a create request deserves special attention, because the ERP may have saved the record even though the caller never got confirmation. Require an identifier or deduplication rule and a lookup before any uncertain write is repeated, and check that the repair keeps the valid work already done.

The coverage checklist

Run this against the workflow's own account, not an administrator's, because an admin login can reach fields and actions the real account can't. Before launch, confirm each of these:

• Every required field can be read, and written where needed.
• Custom fields appear in that account's schema and accept test values.
• Linked records (opportunity, PO, production job) are actually connected, not just created.
• Attachments land on the right record and the reviewer can open them.
• Each business action, such as release or cancel, is tested separately from create.
• The operations owner has confirmed what each mapped field means.
• Uncertain writes are looked up before any retry.
• Every gap has a named fallback owner.

Before launch, operations and IT should sign off on the same matrix: required coverage, verified limits, fallback owners, duplicate handling, and what counts as evidence of completion. Keep it versioned alongside the integration and rerun the affected rows when custom fields, roles, mappings, or business rules change.

What this evidence can and can't tell you

The useful outcome of an API evaluation is a precise statement of what this workflow can complete in your environment, and what it hands to a person. That's worth more than either an enthusiastic connector claim or a long list of supposed ERP limitations.