Developer ToolsFree worksheetPDF, Excel, Word export

ERP API Field Mapping Worksheet for Agent Tools

Most agent integration bugs are mapping bugs: a padded vendor code, a date in the wrong format or an enum that means something different in the database. This worksheet makes the mapping explicit before anyone writes the tool.

Free, optional. Reopen it on any device.

Download:

ERP field	ERP type	Tool parameter	Tool type	Required	Max length	Transform or rule	Exposed to model

Fields mapped

The sample field names are generic, not taken from a specific ERP version. Replace them with the exact field names from your API documentation and mark pricing or personal data as Masked or No.

Check my field mapping

Optionally have a mapping reviewed against your ERP's API for missed code lists and units.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

How to use the worksheet

Start with the ERP endpoint or table and list each field the agent needs, using the exact API name. For each, write the parameter name the model will see, which should be descriptive and human readable, then the types on both sides. Add a transform rule for anything that is not a straight copy, such as padding, case, units or code lists. Finally decide whether the field is exposed to the model, masked or withheld. Export to Excel and share with the ERP functional owner for sign-off.

Design rules for tool parameters

Model-facing names should read like business language, not column names: promise_date, not due_dt. Use enums for code fields and document each value in the tool description so the model does not guess. Accept dates as ISO 8601 and convert on your side. Keep decimals as numbers and state the unit. Keep required fields to the minimum, because every required parameter is one more place for a model to invent a value.

Prefer enums over free text for status and type codes
State units in the parameter description
Validate on the server, never trust the model's format
Mask cost, price and personal fields unless the use case needs them

Reading the example

The sample maps five fields. The vendor number is padded because many ERPs store fixed-width codes, so a model that sends 42 would otherwise miss the record. The status enum shows the translation from a single character to a word the model can reason about. The unit cost is marked Masked so buyers see a price band but not the raw standard cost.

Common mistakes

Skipping the mapping for code lists is the biggest one: the model then sees raw codes and guesses. Others include leaving time zones undefined on datetime fields, exposing internal key fields the user never uses, and forgetting that string comparisons in some databases are case or padding sensitive. Test each row with real records, including empty and maximum-length values.

Frequently Asked Questions

Should I expose every ERP field to the model?

No. Expose only what the use case needs. Fewer fields mean smaller prompts, fewer wrong guesses and less data exposure. Mark sensitive fields as masked or withheld in the worksheet.

How do I handle code lists like status or type?

Map them to descriptive enum values and document each in the tool description. Translate back to the ERP code on the server so the model never has to remember single-letter codes.

What date format should tool parameters use?

ISO 8601, for example 2026-10-20 for dates and 2026-10-20T14:30:00Z for datetimes. Convert to the ERP's native format server-side and state the time zone for datetimes.

Can this worksheet be reused for REST and SQL sources?

Yes. The ERP field column can hold a REST property or a database column. Add the endpoint or table name in the transform column if you map several sources in one sheet.

Netray builds ERP connectors and agents with grounded, role-aware field access. If your mapping spans a legacy ERP with undocumented fields, we can help you work through it.

Talk to an Expert Explore More Free Tools