MerchandAise developer platform
One product workflow. Four ways to connect.
Connect a website, community, supplier operation or enterprise workspace to the same versioned design, quote, approval and order state. Start from the published contract, then plan access and the production rollout with us.
Maintain a single source of truth
An integration should extend the MerchandAise workflow, not fork it. Website, embed, supplier, enterprise and future assistant surfaces must read and update the same versioned design, commerce intent, quote, approval and order state.
Where MerchandAise processes the buyer transaction, Hutter Products GmbH is the contracting seller and Merchant of Record under the MerchandAise brand. Supplier identity and contact details stay private except where disclosure is required, and production still requires digital-proof approval, confirmed producibility, mandatory technical checks, and the sample approvals applicable to the exact accepted order.
01 — Contracts
API and integration surfaces
01
Assistant tooling API docs
Explore current assistant and tooling endpoints for design sessions and integration review. This public reference does not grant anonymous authority to quote or place orders.
Implementation guide
Open assistant tooling docsMachine contract
Assistant tooling OpenAPI JSON/api/docs/openapi.jsonPublic reference for assistant and tooling APIs. Production access and order-affecting operations still require the applicable authorisation.
02
Community embed API
Connect localised club, community or storefront experiences to MerchandAise-owned design and commerce handoffs without rebuilding the underlying workflow.
Machine contract
Community OpenAPI JSON/api/v1/community/public/openapi/v1Public versioned contract for storefront embeds, community discovery and locale-aware handoffs.
03
Supplier API
Connect approved suppliers to onboarding, catalogue, quote and fulfilment operations once the supplier relationship and access model are qualified.
Machine contract
Supplier OpenAPI JSON/api/v1/supplier/openapi/v1Public contract for planning and client generation. Operational supplier access remains permissioned.
04
Enterprise identity API
Plan SSO, SCIM provisioning and audit-ready identity flows for approved company merchandise programmes and governed rollouts.
Machine contract
Enterprise identity OpenAPI JSON/api/v1/enterprise/identity/openapi/v1Protected contract for approved enterprise workspaces; request access before using this endpoint.
02 — Implementation guide
Choose the contract before the code
- 01
Map the user journey
Decide who enters the workflow and where: a buyer in an embedded storefront, an approved supplier, an enterprise user, or an assistant operating with explicit authorisation.
- 02
Confirm the access boundary
Use public contracts for evaluation and client generation, then confirm credentials, scopes, environments, callbacks and protected endpoints before implementation.
- 03
Prove state continuity
Test that designs, quotes, approvals, errors and order handoffs remain version-current across the integration, including retries and rollback paths.
03 — What every integration must preserve
What every integration must preserve
One versioned state
Design, commerce intent, supplier-backed quote, approval and order status stay connected. Stale changes must trigger a visible re-quote or review state.
Commercial and supplier privacy
MerchandAise remains the buyer-facing merchant and support owner. Supplier identities, contacts and internal data are not exposed through public integrations.
Approval before production
A 3D view is not physical evidence. The confirmed quote explains any available customer-sample choices, costs, limitations, and timing. Approve the exact digital proof and complete mandatory technical checks and any required or selected sample approval before mass production. Existing accepted-order requirements remain binding.
04
Before production traffic
A published OpenAPI file is a planning surface, not a promise of anonymous production access. We review environments, credentials, failure handling and operational ownership before go‑live.
Access and environments
Confirm the contract version, approved workspace, authentication scopes, sandbox and production credentials, and callback destinations.
Failure and recovery
Define retries, idempotency, timeouts, customer-visible errors, observability, support ownership and rollback before release.
End-to-end evidence
Verify the intended journey in staging from entry and state mutation through quote, approval, handoff and recovery behaviour.
FAQ
Which integration surface should I start with?
Start with the person and state transition. Use community embeds for buyer-facing club or community journeys, supplier operations for approved supply-side workflows, enterprise identity for SSO and SCIM, and assistant tooling only for explicitly authorised AI-led flows.
Does a public contract mean public production access?
No. A public OpenAPI contract supports discovery, architecture review and client generation. Production credentials, write operations, supplier workflows, enterprise identity and assistant execution can still require an approved workspace and scoped authorisation.
Can an integration expose suppliers or bypass approvals?
No. Supplier identity and contact details remain private except where disclosure is required, MerchandAise owns the buyer relationship, and order-affecting actions must preserve the configured digital-proof, technical, and order-specific sample approval requirements.
Bring us the workflow, not a finished architecture.
Tell us who will use the integration, which state they need to read or change, and where the experience will live. We'll map the contract, access model and safest rollout path with you.