Onboarding von Handelspartnern
Prüfen Sie Beispieldaten eines Partners, erkennen Sie Struktur und Standortfelder, bereiten Sie Zuordnungen vor und belegen Sie den Intake-Pfad, bevor eine produktive Handelspartnerverbindung freigegeben wird.
A tested partner intake profile with sample data, mapping decisions, validation findings, and a clear handoff into production onboarding.
The job today
Onboarding usually starts with sample files, implementation guides, partner identifiers, spreadsheet mappings, email questions, and repeated checks against location, item, customer, or trading-partner masters. Much of the early effort is understanding the data and preparing a mapping for review.
A useful first agent request
Inspect this representative partner sample for the authorized onboarding task. Detect the schema, preview the normalized rows, identify likely location fields and stable identifiers, and propose a source-to-target mapping review list. Flag ambiguity instead of guessing. Do not write or promote a production mapping.
Use this playbook when
- A new customer, supplier, carrier, 3PL, marketplace, or other partner needs to exchange EDI, EDIFACT, cXML, files, or API data.
- The partner has supplied samples, specifications, or credentials, but the receiving team still needs to understand fields, identifiers, mappings, and exceptions.
- You want to prove the onboarding design before committing production credentials, schedules, or routing.
What you need
- Representative partner samples and the document or message types expected in production.
- The partner identifiers and business keys that must survive normalization, such as trading-partner IDs, order numbers, item IDs, GLNs, GTINs, or customer location codes.
- The intended intake method and delivery method, such as API, SFTP, AS2, file exchange, webhook, or another approved connector.
- The business destination for the normalized data: locations, items, inventory, CRM, replenishment, telemetry, or another approved workflow.
What this should produce
- A documented source schema and field inventory based on representative samples.
- A proposed and reviewed mapping from partner fields to the Atlasemoji or customer-owned target model.
- A testable onboarding checklist covering transport, translation boundary, identifiers, mapping, validation, exceptions, and production handoff.
Operating playbook
- 1
Collect representative samples
Use real-looking samples that cover normal records and known edge cases. A partner specification without representative data is not enough to prove the onboarding path.
- 2
Detect structure before discussing mapping
Identify delimiters, columns, nested fields, document structures, and likely location or identifier fields. Confirm what is actually present in the sample instead of mapping from assumptions.
- 3
Define the translation boundary
Decide where EDI, EDIFACT, cXML, or proprietary translation occurs. It can remain in an existing translator, VAN, iPaaS, partner system, or customer-owned service. Atlasemoji does not need to replace a translator that already works.
- 4
Map business meaning, not just column names
Map the fields to the operational destination and preserve stable partner identifiers. Use XREF or partner mapping where two systems use different codes for the same item, location, account, carrier, or other business object.
- 5
Test the sample and the failure path
Preview normalized rows, validate required fields, identify rejected records, and document what happens when a required identifier, location, or value is missing.
- 6
Promote only the proven contract
After the sample, mapping, exceptions, and delivery behavior are agreed, create the production transport and credential configuration through the approved integration path. Keep production secrets out of MCP prompts and test artifacts.
Agent access for this playbook
Think of each MCP tool as a bounded API capability packaged for an agent: a defined operation, accepted inputs, approved tenant/resource scope, and returned result. The agent can reason across the tools it has been given, but the connection and underlying API authorization still determine what those tools can reach and do.
What the agent may inspect
- The supplied or authorized sample structure and schema.
- A bounded preview of DataSynch rows and detected location columns when those tools are used.
- A proposed field mapping for human review; the proposal is not production configuration.
What this Atlasemoji MCP tool set is not authorized to do
- The current public Atlasemoji MCP tool set is not authorized to save or promote a production mapping, create partner credentials, or turn on a production connector.
- It does not decide that two ambiguous customer, item, or location identifiers are equivalent without evidence and review.
Where a person stays in control
- A person approves the target fields, stable identifiers, XREF decisions, required defaults, and exception behavior.
- A person or approved deployment process authorizes credentials, production connectivity, writes, and promotion.
How the data stays bounded
Limit the task to the supplied or authorized sample, the intended company/workspace/manifest, and the schema, preview, location-detection, and mapping tools needed for onboarding. Those MCP tools are bounded API-backed capabilities; Atlasemoji applies the connection credential and tenant/resource context behind the tool calls. The agent does not need a general-purpose production credential or broad access to unrelated partner records to prepare the onboarding review.
Atlasemoji bounds agent access through the connection and the API-backed capabilities behind each tool. Issued credentials or API keys, tenant context, tool scope, resource identifiers such as workspace or manifest, permitted action, and environment all contribute to the authorization boundary. The agent works through the approved tool contract rather than receiving blanket platform access.
Read-only is the policy of the public Atlasemoji MCP tool set documented today, not a limitation of MCP itself. A customer or partner can separately approve additional API-backed tools with narrower or broader read, write, execution, or production scopes for a specific relationship.
Decision points
- If translation already works elsewhere, keep it there and send normalized or translated data into Atlasemoji.
- If the same business object has different partner codes, solve the identity problem with stable IDs/XREF before adding downstream business logic.
- If required data is absent from the sample, resolve that contract with the partner rather than hiding the gap in a mapping rule.
- If the proof depends on production credentials or production writes, stop the sandbox proof at the boundary and move that step into the approved onboarding process.
Two access patterns, one Atlasemoji platform
Atlasemoji APIs are foundational in both patterns. A direct REST integration calls documented APIs from your application. An MCP integration lets an AI agent use selected Atlasemoji API and service capabilities through typed tools, with agent-oriented discovery, tool scoping, tenant/resource context, and policy controls around those calls.
Call Atlasemoji APIs directly from your code
Use the direct API path when your application already knows the exact operation it needs to perform. Your code authenticates, calls the documented endpoint, supplies the required company/workspace/manifest or object context, and receives the machine-readable result. This is ideal for repeatable, deterministic integration behavior.
Application / integration → API credential → Atlasemoji API → approved capability → resultLet an agent work through approved API-backed tools
Use MCP when the request is variable and benefits from an agent choosing among approved capabilities, comparing evidence, validating context, or explaining the next step. The agent calls MCP tools; Atlasemoji maps those tools to the underlying authorized API/service capabilities. The current public Atlasemoji tool set is intentionally read-only.
Person / AI agent → Atlasemoji MCP → approved tool → Atlasemoji API/service → approved capability → resultMCP is not a black box around the APIs
The MCP layer packages selected Atlasemoji API/service capabilities as tools an agent can discover and call. That lets Atlasemoji keep API credentials, tenant/resource boundaries, permitted actions, and audit context attached to the capability while giving the agent a simpler task-oriented interface. The tool may orchestrate one or more underlying calls, but it does not bypass the API and authorization model.
You can build both paths for the same business question and compare them. Useful measures include time to answer, manual searches removed, latency, successful-answer rate, escalation rate, cost per task, and how often a person needs to intervene. Many production designs will use both: direct APIs for deterministic automation and MCP for agent-led investigation, interpretation, and orchestration.
Direct REST/API production path
Keep the system of record where it already belongs. Atlasemoji can normalize, connect, validate, add geographic context, expose APIs, host integrations, and coordinate exceptions without forcing the entire process into one application.
- Use the DataSynch developer and integration interfaces to define the intake, target workflow, field mapping, exception handling, and delivery path.
- Use partner or customer translation infrastructure when that is already the right place for document translation.
- Use Atlasemoji APIs for normalization, operational data, locations, XREF, testing, and downstream workflows that belong in Atlasemoji.
- Promote credentials, schedules, and production delivery only after sample-data behavior is accepted.
Relevante API- und Hilfepfade
These pages are not duplicates. Each one answers a different question in the build process: what route exists, how several routes work together, what a valid request looks like, or what a business capability is meant to do.
DataSynch API Explorer →
The searchable DataSynch API reference. Search by business job, route, schema, tag, object type, or app surface. Each route explains what it does, the context it requires, its related schema, the next logical route, and the full Swagger contract.
Search receiver, normalize, XREF, master tables, and locations. Follow the Required context, Related schema, and Next step fields to turn a partner sample into an intake sequence.
DataSynch Workbench →
A guided build surface for seeing how DataSynch routes work together. It includes workflows for imports, XREF, geofences, telemetry, dispatch, and run logs so you can understand the sequence before wiring it into your own application.
Use guided import and XREF workflows to see how a sample moves from intake to normalized records and identifier resolution before writing production configuration.
DataSynch API Examples →
Known-good DataSynch request bodies. Use these after you know which route you need and want a concrete payload to compare with your own JSON, partner data, or integration test.
Use examples to compare the partner sample with known-good intake/import request bodies instead of guessing the JSON shape from a route name.
DataSynch Developer Center →
The orientation page for DataSynch developers. Use it when you are not yet sure whether you need the API Explorer, Workbench, examples, quick starts, GCP guidance, or a direct/non-GCP integration path.
Start here if you still need to choose between a connector/GCP path, direct API path, Workbench proof, or sample-driven implementation.
EDI, EDIFACT & cXML →
The EDI, EDIFACT & cXML solution connects B2B document flows, testing, diagnosis, and integration choices. Use it to decide which part belongs in Atlasemoji and which part should remain in an existing translator, VAN, iPaaS, or partner system.
Use this to decide where document translation, envelope handling, partner testing, and normalized-data handoff belong in the onboarding architecture.
Agentic path through MCP and Atlasemoji APIs
Atlasemoji MCP is an agent-facing way to use selected Atlasemoji API and service capabilities through typed tools. The MCP server authenticates the connection, exposes the approved tool surface, and invokes the underlying capabilities with the permitted company, workspace, manifest, resource, and action context. Atlasemoji's current public tool set is read-only and non-destructive by design; that is a property of this tool set, not a limitation of MCP or APIs.
Connect this playbook to ChatGPT
Start by proving the playbook in one ChatGPT conversation. Connect Atlasemoji as a remote MCP app, verify the exact tools this playbook needs, and run the first request with authorized IDs. Remember what is happening underneath: ChatGPT calls the Atlasemoji MCP tool; Atlasemoji authorizes that tool and uses the corresponding API/service capability within the approved tenant and resource scope.
- 1
Get approved Atlasemoji MCP access
Obtain approved Atlasemoji MCP access and the company, workspace, or manifest identifiers you are authorized to use. Atlasemoji-issued credentials are part of the connection and authorization boundary; the endpoint alone does not grant tenant data access.
- 2
Open ChatGPT custom-app setup
On a supported ChatGPT web plan/workspace, enable Developer mode and open Settings → Apps → Create. Workspace administrators can also create the app from Workspace settings → Apps → Create. If those controls are not available, check the current OpenAI help page below or ask your workspace administrator.
- 3
Add the Atlasemoji remote MCP endpoint
Enter https://atlasemoji.com/api/mcp as the remote server endpoint. Atlasemoji documents Streamable HTTP transport and an Atlasemoji-issued bearer credential. Select the ChatGPT authentication option that matches the access method provided for your Atlasemoji relationship; Atlasemoji support can help if your workspace needs a different supported connection method.
- 4
Scan the tools and compare them with this playbook
Use ChatGPT's Scan Tools step, then compare the discovered tools with the list shown below. Each listed tool represents a bounded Atlasemoji capability with defined inputs and outputs; behind the MCP surface, Atlasemoji invokes the corresponding authorized API/service logic rather than giving the agent unrestricted platform access.
- 5
Run one real test in a new chat
Select the Atlasemoji draft app in a new ChatGPT conversation and paste the first test request below. Replace placeholder IDs with authorized values. Evaluate both the answer and the path used to get there: which tools were called, which tenant/resource context was used, and whether the evidence was sufficient.
- 6
Make the working pattern reusable
After the test works, make the pattern reusable if your ChatGPT workspace supports Workspace Agents. Add only the apps/tools needed for the job and choose the appropriate end-user or agent-owned connection model. You can also keep the workflow as a normal ChatGPT conversation or pair it with a direct REST integration.
https://atlasemoji.com/api/mcpTransport: Streamable HTTP. Authentication: Atlasemoji-issued bearer credential. MCP tools are backed by approved Atlasemoji API/service capabilities and remain bounded by the connection, tool scope, tenant/resource context, and permitted action.
detect_file_schemadetect_location_columnspreview_datasynch_rowssuggest_field_mappingInspect this representative partner sample for the authorized onboarding task. Detect the schema, preview the normalized rows, identify likely location fields and stable identifiers, and propose a source-to-target mapping review list. Flag ambiguity instead of guessing. Do not write or promote a production mapping.
Current MCP tools used
detect_file_schemadetect_location_columnspreview_datasynch_rowssuggest_field_mappingProfile a new partner sample
Inspect this representative partner sample. Detect the schema, identify likely business identifiers and location fields, preview the normalized rows, and list the fields that need a mapping decision. Do not write or promote anything.
Prepare a mapping review
Using the approved sample and target field list, suggest a field mapping and call out ambiguous, missing, or conflicting fields that require a human decision before onboarding proceeds.