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 with the published contract, then plan access and production rollout with us.

Keep one 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 and genuine-sample approval.

01 — Contracts

API and integration surfaces

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 an order.

Access: public

Implementation guide

Read assistant tooling docs

Machine contract

Assistant tooling OpenAPI JSON

/api/docs/openapi.json

Public reference for assistant and tooling APIs. Production access and order-affecting operations still require the applicable authorization.

Community embed API

Connect localized club, community, or storefront experiences to MerchandAise-owned design and commerce handoffs without rebuilding the underlying workflow.

Access: public

Machine contract

Community OpenAPI JSON

/api/v1/community/public/openapi/v1

Public versioned contract for storefront embeds, community discovery, and locale-aware handoffs.

Supplier API

Connect approved suppliers to onboarding, catalog, quote, and fulfillment operations after the supplier relationship and access model are qualified.

Access: public

Machine contract

Supplier OpenAPI JSON

/api/v1/supplier/openapi/v1

Public contract for planning and client generation. Operational supplier access remains permissioned.

Enterprise identity API

Plan SSO, SCIM provisioning, and audit-ready identity flows for approved company merchandise programs and governed rollouts.

Access: protected

Machine contract

Enterprise identity OpenAPI JSON

/api/v1/enterprise/identity/openapi/v1

Protected 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 authorization.
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 stay 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 product-native 3D view and digital proof support the decision, but they do not replace the genuine production sample required before mass production.

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, 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 behavior.

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 authorized 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 authorization.

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 approval and genuine-sample gates.

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 will map the contract, access model, and safest rollout path with you.

Plan an integration Explore AI agents and MCP

Keep one source of truth

Choose the contract before the code

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 authorization.

Confirm the access boundary

Use public contracts for evaluation and client generation, then confirm credentials, scopes, environments, callbacks, and protected endpoints before implementation.

Prove state continuity

Test that designs, quotes, approvals, errors, and order handoffs stay version-current across the integration, including retries and rollback paths.

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 product-native 3D view and digital proof support the decision, but they do not replace the genuine production sample required before mass production.

FAQ

Which integration surface should I start with?

Does a public contract mean public production access?

Can an integration expose suppliers or bypass approvals?