Core Concepts
MyIntegrationHub organizes your integration landscape through a clear hierarchy of objects. Understanding these core concepts helps you structure your partner onboarding efficiently.
Workspace
A workspace is your top-level organizational unit. It represents a project, department, or client environment. All partners, integrations, and specifications live within a workspace.
Partner
A partner represents an external entity you exchange data with — a customer, supplier, logistics provider or any third party. Partners have contact details, status tracking and associated integrations.
Integration
An integration defines how data flows between you and a partner — direction (inbound/outbound), protocol type (REST API, EDI, XML, etc.), endpoint URL and current status.
Specification
A specification describes the data format for an integration — field definitions, types, nesting, validation rules, and sample payloads. Specifications have versions and go through approval workflows.
Approval
Approvals track sign-off processes for specification changes, integration updates, or go-live decisions. Assign reviewers, set due dates, and track status through Pending → In Review → Approved.
Checklist
Checklists ensure nothing gets missed during onboarding. Create reusable templates with categorized items and track completion per partner for a structured go-live process.
Checklist Template
Checklist Templates are reusable blueprints for onboarding processes. Define a set of categorized items with required flags once, then apply the template consistently to every new partner.
Test Case
Test Cases validate your integrations against their specifications. They can be derived from payload fields, validation rules, or sample payloads, covering positive, negative, boundary and process scenarios.
Document
Store and share files related to your integrations — technical documentation, mapping sheets, test reports, or any file relevant to your partner onboarding.
Comment
Add contextual comments to specifications, approvals, or any object. Comments create an audit trail and facilitate communication between team members and partners.
How Objects Relate
The objects in MyIntegrationHub form a clear hierarchy. Understanding their relationships helps you organize your integration landscape efficiently.
Key Relationships
See It in Action
Explore the partner view below. Click on a partner to see how integrations, specifications, and approvals are organized within a partner context.
Partners
3 Partners| Name | Type | Status | Contact | Integrations |
|---|---|---|---|---|
| Acme Corp | Customer | Active | John Miller | 3 |
| GlobalTrade Ltd | Supplier | Onboarding | Sarah Chen | 1 |
| TechFlow GmbH | Logistics | Active | Max Weber | 2 |
↑ Click on a partner to see the detail view
Typical Workflow
Follow this step-by-step workflow to onboard a new partner and document your integration completely. Each step builds on the previous one.
↑ Click on each step to advance the workflow
Acme Corp — Go-Live Checklist
3/6↑ Click items to toggle their completion status
Workflow Details
Create Partner
Navigate to Partners in the sidebar and click + New Partner. Fill in the partner name, type (Customer, Supplier, Logistics, etc.), contact information, and any relevant notes.
Define Integration
Go to Integrations and create a new integration. Specify the partner name, direction (Inbound or Outbound), type (REST API, EDI, XML, CSV, etc.), endpoint URL and an initial status.
Create Specification
Under Specifications, create a new specification and link it to the integration. Set the format type, initial version number, and provide a description of the data contract.
Enrich the Specification
Open the specification detail page and work through the tabs: Payload Structure to define fields and their types, Validation Rules for business constraints, and Sample Payload with a real-world example.
Request Approval & Version
Create an Approval to submit the specification for review. Once approved, use the Version History tab to create a version snapshot. This preserves the approved state and allows future changes to be tracked.
Examples
Explore these real-world examples to understand how different integration types are documented in MyIntegrationHub.
REST JSON Order Specification
This example shows a complete JSON-based order specification with payload structure, validation rules, and a sample payload. Click through the tabs to explore each section.
REST Order Payload
In Reviewv1.0JSON payload specification for outbound order data via REST API. Includes customer information, order items with SKU/quantity/price, and total calculation.
↑ Click through the tabs to explore the specification views
EDI 850 Purchase Order
EDI integrations follow the same structure. Below is an example of how an EDI specification looks in the system.
EDI 850 Purchase Order
Approvedv2.1Sample EDI Segments
ISA*00* *00* *ZZ*ACME *ZZ*PARTNER *250320*1200*U*00401*000000001*0*P*>~
GS*PO*ACME*PARTNER*20250320*1200*1*X*004010~
ST*850*0001~
BEG*00*NE*ORD-2025-001**20250320~
N1*BY*Acme Corp*92*ACME001~
PO1*1*10*EA*29.99**VP*WIDGET-001~
CTT*1~
SE*7*0001~XML Shipping Notice (ASN)
XML-based specifications support nested structures. The system auto-detects the format and validates syntax.
ASN XML Schema
Draftv1.2<?xml version="1.0" encoding="UTF-8"?>
<ShippingNotice>
<Header>
<NoticeID>ASN-2025-042</NoticeID>
<ShipDate>2025-03-20</ShipDate>
<Carrier>DHL Express</Carrier>
</Header>
<Shipment>
<TrackingNumber>1Z999AA10123456784</TrackingNumber>
<Origin>
<City>Hamburg</City>
<Country>DE</Country>
</Origin>
<Destination>
<City>New York</City>
<Country>US</Country>
</Destination>
</Shipment>
<Items>
<Item sku="WIDGET-001" quantity="10" />
<Item sku="GADGET-002" quantity="5" />
</Items>
</ShippingNotice>Specification Change Approval
When specification changes need sign-off, create an Approval. Here is how the approval workflow looks:
EDI 850 v2.1 Release
ApprovedChecklist Template
Create reusable templates with categorized items and required flags. Apply them to each new partner for a consistent onboarding process.
Checklist Template — API Integration Setup
8 Items| # | Title | Category | Required |
|---|---|---|---|
| 1 | API credentials provisioned | Setup | ● |
| 2 | Endpoint URL configured | Setup | ● |
| 3 | Authentication method verified | Technical | ● |
| 4 | Payload structure defined | Technical | ● |
| 5 | Validation rules documented | Documentation | ○ |
| 6 | Sample payload tested | Testing | ● |
| 7 | Error handling verified | Testing | ○ |
| 8 | Go-live approval obtained | Approval | ● |
Test Cases from Specification
Test cases can be derived from your specification fields, validation rules, and sample payloads. Each test case verifies a specific aspect of the integration.
Test Cases — REST Order Payload
6 Test Cases| Code | Title | Test Type | Source | Status |
|---|---|---|---|---|
| TC-001 | Valid order payload accepted | positive | sample_payload | ready |
| TC-002 | Missing required field order_id rejected | negative | payload_field | ready |
| TC-003 | Invalid email format rejected | negative | validation_rule | draft |
| TC-004 | Empty items array rejected | boundary | validation_rule | ready |
| TC-005 | Quantity zero rejected | boundary | validation_rule | draft |
| TC-006 | Total amount equals sum of items | process | validation_rule | reviewed |
↑ Click on a test case to see its details
FAQ & Best Practices
Common questions and recommendations for getting the most out of MyIntegrationHub.
Ready to Get Started?
Create your free account and start managing your integration partners today.