Piattaforma sviluppatori MerchandAise

Un flusso di prodotto. Quattro modalità di integrazione.

Collega un sito, una community, l’operazione di un fornitore o lo spazio aziendale allo stesso design versionato, preventivo, approvazione e stato dell’ordine. Parti dal contratto pubblicato, poi pianifica con noi accessi e rollout di produzione.

Mantieni un’unica fonte di verità

Un’integrazione deve estendere il workflow di MerchandAise, non crearne una copia. Siti web, embed, fornitori, ambienti enterprise e future superfici assistant devono leggere e aggiornare lo stesso design versionato, intento commerciale, preventivo, stato di approvazione e ordine.

Quando MerchandAise gestisce la transazione d’acquisto, Hutter Products GmbH è il venditore contraente e Merchant of Record sotto il marchio MerchandAise. L’identità e i contatti del fornitore restano riservati salvo obblighi di divulgazione, e la produzione richiede comunque l’approvazione del digital proof e del campione reale.

01 — Contratti

API e superfici di integrazione

Documentazione API per gli strumenti dell'assistente

Esplora gli endpoint attuali per l'assistente e gli strumenti per le sessioni di progettazione e la revisione dell'integrazione. Questo riferimento pubblico non concede l'autorizzazione anonima per richiedere preventivi o effettuare ordini.

Accesso: public

Guida di implementazione

Apri la documentazione degli strumenti dell'assistente

Contratto macchina

OpenAPI JSON per gli strumenti dell'assistente

/api/docs/openapi.json

Riferimento pubblico per i API dell'assistente e degli strumenti. L'accesso di produzione e le operazioni che influiscono sugli ordini richiedono comunque l'autorizzazione applicabile.

API di incorporamento della community

Collega le esperienze localizzate di club, community o vetrine ai passaggi di consegne commerciali e di design di proprietà di MerchandAise, senza dover ricostruire il flusso di lavoro sottostante.

Accesso: public

Contratto macchina

OpenAPI JSON della community

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

Contratto pubblico con controllo di versione per incorporamenti di vetrine, scoperta della community e passaggi di consegne sensibili alla localizzazione.

API fornitori

Collega i fornitori approvati alle operazioni di onboarding, catalogo, preventivo ed evasione degli ordini, previa qualificazione della relazione con il fornitore e del modello di accesso.

Accesso: public

Contratto macchina

OpenAPI JSON fornitori

/api/v1/supplier/openapi/v1

Contratto pubblico per la pianificazione e la generazione di client. L'accesso operativo per i fornitori rimane soggetto ad autorizzazione.

API di identità aziendale

Pianifica SSO, il provisioning SCIM e flussi di identità pronti per l'audit per i programmi di merchandising aziendali approvati e i rilasci controllati.

Accesso: protected

Contratto macchina

OpenAPI JSON di identità aziendale

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

Contratto protetto per aree di lavoro aziendali approvate; richiedi l'accesso prima di utilizzare questo endpoint.

02 — Guida di implementazione

Scegli il contratto prima del codice

01
Mappa il journey dell’utente
Decidi chi entra nel workflow e dove: un acquirente in uno storefront embedded, un fornitore approvato, un utente enterprise o un assistant che opera con autorizzazione esplicita.
02
Conferma il confine di accesso
Usa i contratti pubblici per valutazione e generazione client, quindi conferma credenziali, scope, ambienti, callback ed endpoint protetti prima dell’implementazione.
03
Dimostra la continuità di stato
Verifica che design, preventivi, approvazioni, errori e passaggi d’ordine rimangano aggiornati alla versione corrente attraverso l’integrazione, inclusi retry e percorsi di rollback.

03 — Cosa ogni integrazione deve preservare

Cosa ogni integrazione deve preservare

Uno stato versionato

Design, intento commerciale, preventivo supportato dal fornitore, approvazione e stato ordine restano connessi. Modifiche obsolete devono attivare un re-quote visibile o uno stato di revisione.

Riservatezza commerciale e del fornitore

MerchandAise resta il referente commerciale verso l’acquirente e il referente supporto. Identità, contatti e dati interni del fornitore non sono esposti tramite integrazioni pubbliche.

Approvazione prima della produzione

La visualizzazione 3D nativa del prodotto e il digital proof supportano la decisione, ma non sostituiscono il campione reale richiesto prima della produzione di massa.

Prima del traffico di produzione

Un file OpenAPI pubblicato è una base di pianificazione, non una promessa di accesso di produzione anonimo. Revisioniamo ambienti, credenziali, gestione dei guasti e ownership operativa prima del go-live.

Accesso e ambienti

Conferma la versione del contratto, lo workspace approvato, gli scope di autenticazione, sandbox, credenziali di produzione e le destinazioni di callback.

Guasto e ripristino

Definisci retry, idempotenza, timeout, errori visibili al cliente, osservabilità, ownership del supporto e rollback prima del rilascio.

Evidenza end-to-end

Verifica il percorso previsto in staging dall’entry e la mutazione dello stato fino a preventivo, approvazione, handoff e comportamento di recovery.

FAQ

Con quale superficie d’integrazione dovrei iniziare?

Inizia dalla persona e dalla transizione di stato. Usa gli embed community per percorsi buyer-facing di club o community, le integrazioni fornitore per workflow lato supply approvati, enterprise identity per SSO e SCIM, e assistant tooling solo per flussi AI esplicitamente autorizzati.

Un contratto pubblico significa accesso di produzione pubblico?

No. Un contratto OpenAPI pubblico serve per discovery, revisione architetturale e generazione client. Credenziali di produzione, operazioni in scrittura, workflow fornitore, identità enterprise e l’esecuzione assistant possono comunque richiedere uno workspace approvato e autorizzazioni con scope.

Un’integrazione può esporre i fornitori o bypassare le approvazioni?

No. L’identità e i contatti dei fornitori restano privati salvo obblighi di divulgazione, MerchandAise detiene la relazione verso l’acquirente e le azioni che incidono sugli ordini devono preservare le regole di approvazione e il requisito del campione reale.

Portaci il workflow, non un’architettura finita.

Dicci chi userà l’integrazione, quale stato deve leggere o modificare e dove vivrà l’esperienza. Mappiamo insieme contratto, modello di accesso e percorso di rollout più sicuro.

Pianifica un’integrazione Scopri AI agents e MCP

Mantieni un’unica fonte di verità

Scegli il contratto prima del codice

Mappa il journey dell’utente

Decidi chi entra nel workflow e dove: un acquirente in uno storefront embedded, un fornitore approvato, un utente enterprise o un assistant che opera con autorizzazione esplicita.

Conferma il confine di accesso

Usa i contratti pubblici per valutazione e generazione client, quindi conferma credenziali, scope, ambienti, callback ed endpoint protetti prima dell’implementazione.

Dimostra la continuità di stato

Verifica che design, preventivi, approvazioni, errori e passaggi d’ordine rimangano aggiornati alla versione corrente attraverso l’integrazione, inclusi retry e percorsi di rollback.

Cosa ogni integrazione deve preservare

Uno stato versionato

Design, intento commerciale, preventivo supportato dal fornitore, approvazione e stato ordine restano connessi. Modifiche obsolete devono attivare un re-quote visibile o uno stato di revisione.

Riservatezza commerciale e del fornitore

MerchandAise resta il referente commerciale verso l’acquirente e il referente supporto. Identità, contatti e dati interni del fornitore non sono esposti tramite integrazioni pubbliche.

Approvazione prima della produzione

La visualizzazione 3D nativa del prodotto e il digital proof supportano la decisione, ma non sostituiscono il campione reale richiesto prima della produzione di massa.

FAQ

Con quale superficie d’integrazione dovrei iniziare?

Un contratto pubblico significa accesso di produzione pubblico?

Un’integrazione può esporre i fornitori o bypassare le approvazioni?