MerchandAise udviklerplatform

Én produktarbejdsgang. Fire måder at integrere på.

Tilslut et website, en community-oplevelse, en leverandørs drift eller et virksomhedsarbejdsrum til samme versionerede design-, tilbuds-, godkendelses- og ordretilstand. Start med den publicerede kontrakt, og planlæg så adgang og produktionsudrulning sammen med os.

Bevar én sandhedskilde

En integration bør udvide MerchandAise-arbejdsgangen — ikke danne en parallel. Website-, embed-, leverandør-, virksomheds- og fremtidige assistentflader skal læse og opdatere samme versionerede design, kommercielle hensigt, tilbud, godkendelse og ordretilstand.

Hvor MerchandAise håndterer købertransaktionen, er Hutter Products GmbH den kontraherende sælger og Merchant of Record under MerchandAise-brandet. Leverandøridentitet og kontaktoplysninger forbliver private, medmindre videregivelse er påkrævet, og produktion kræver stadig digitalt proof og godkendelse af en ægte produktprøve.

01 — Kontrakter

API og integrationsflader

Assistentværktøj API-dokumentation

Udforsk aktuelle assistent- og værktøjsendepunkter til designsessions og integrationsgennemgang. Denne offentlige reference giver ikke anonym tilladelse til at give tilbud eller afgive en ordre.

Adgang: public

Implementeringsvejledning

Åbn dokumentation for assistentværktøjer

Maskinkontrakt

Assistentværktøj OpenAPI JSON

/api/docs/openapi.json

Offentlig reference for assistent- og værktøjs-APIer. Produktionsadgang og ordre-påvirkende handlinger kræver fortsat den relevante godkendelse.

Fællesskabsindlejring API

Forbind lokaliserede klub-, fællesskabs- eller webshopoplevelser til MerchandAise-ejede design- og handelsoverdragelser uden at genopbygge den underliggende arbejdsgang.

Adgang: public

Maskinkontrakt

Fællesskabs-OpenAPI JSON

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

Offentlig versionsstyret kontrakt for webshopindlejringer, fællesskabsopdagelse og lokalitetsbevidste overdragelser.

Leverandør-API

Forbind godkendte leverandører til onboarding-, katalog-, tilbuds- og opfyldelsesprocesser, efter at leverandørforholdet og adgangsmodellen er kvalificeret.

Adgang: public

Maskinkontrakt

Leverandør-OpenAPI JSON

/api/v1/supplier/openapi/v1

Offentlig kontrakt til planlægning og klientgenerering. Operationel leverandøradgang kræver fortsat tilladelse.

Virksomhedsidentitet API

Planlæg SSO, SCIM-klargøring og overvågningsklare identitetsflow for godkendte virksomhedsmerchandise-programmer og kontrollerede udrulninger.

Adgang: protected

Maskinkontrakt

Virksomhedsidentitet OpenAPI JSON

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

Beskyttet kontrakt for godkendte virksomhedsarbejdsområder. Anmod om adgang, før du bruger dette endepunkt.

02 — Implementeringsvejledning

Vælg kontrakten før koden

01
Kortlæg brugerrejsen
Beslut hvem der træder ind i arbejdsgangen og hvor: en køber i et indlejret butiksvindue, en godkendt leverandør, en virksomhedsanvender eller en assistent med udtrykkelig autorisation.
02
Bekræft adgangsgrænsen
Brug offentlige kontrakter til evaluering og klientgenerering, og bekræft derefter legitimationsoplysninger, scopes, miljøer, callbacks og beskyttede endpoints inden implementering.
03
Bevis kontinuitet i tilstand
Test at designs, tilbud, godkendelser, fejl og ordreoverleveringer forbliver versionsaktuelle på tværs af integrationen, inklusive retry- og rollback-scenarier.

03 — Hvad enhver integration skal bevare

Hvad enhver integration skal bevare

Én versioneret tilstand

Design, kommerciel hensigt, leverandørbacked tilbud, godkendelse og ordrestatus forbliver forbundet. Forældede ændringer skal udløse en synlig genberegning af tilbud eller en gennemgangstilstand.

Kommerciel og leverandørfortrolighed

MerchandAise forbliver den købervendte handels- og supportansvarlige. Leverandørers identiteter, kontakter og interne data eksponeres ikke gennem offentlige integrationer.

Godkendelse før produktion

En produkt-native 3D-visualisering og digitalt proof understøtter beslutningen, men de erstatter ikke den ægte produktprøve, der kræves før masseproduktion.

Før produktions-trafik

En publiceret OpenAPI-fil er et planlægningsinstrument, ikke en garanti for anonym produktionsadgang. Vi gennemgår miljøer, legitimationsoplysninger, fejlbehandling og operationelt ansvar før go-live.

Adgang og miljøer

Bekræft kontraktversion, godkendt workspace, autentificeringsscopes, sandbox, produktionslegitimationsoplysninger og callback-destinationer.

Fejl og genopretning

Definér retries, idempotens, timeouts, kunde-synlige fejl, observability, supportansvar og rollback før frigivelse.

End-to-end-bevis

Verificér den tiltænkte rejse i staging fra indgang og tilstandsændring gennem tilbud, godkendelse, overlevering og genopretningsadfærd.

FAQ

Hvilken integrationsflade skal jeg starte med?

Start med personen og tilstandsovergangen. Brug community-embeds til købervendte klub- eller community-rejser, leverandørdrift til godkendte supply-side-workflows, enterprise identity til SSO og SCIM, og assistentværktøj kun til udtrykkeligt autoriserede AI-ledede flows.

Betyder en offentlig kontrakt offentlig produktionsadgang?

Nej. En offentlig OpenAPI-kontrakt understøtter opdagelse, arkitekturgennemgang og klientgenerering. Produktionslegitimationsoplysninger, skriveoperationer, leverandørworkflows, virksomhedsidensitet og assistentudførelse kan stadig kræve et godkendt workspace og scoped autorisation.

Kan en integration eksponere leverandører eller omgå godkendelser?

Nej. Leverandøridentitet og kontaktoplysninger forbliver private, medmindre videregivelse er påkrævet. MerchandAise ejer køberrelationen, og handlinger, der påvirker ordrer, skal bevare den konfigurerede godkendelses- og ægte-prøve-godkendelsesproces.

Medbring arbejdsgangen, ikke en færdig arkitektur.

Fortæl os, hvem der skal bruge integrationen, hvilken tilstand de skal kunne læse eller ændre, og hvor oplevelsen bliver hostet. Vi kortlægger kontrakten, adgangsmodellen og den sikreste udrulningsvej sammen med jer.

Planlæg en integration Udforsk AI-agenter og MCP

Bevar én sandhedskilde

Vælg kontrakten før koden

Kortlæg brugerrejsen

Beslut hvem der træder ind i arbejdsgangen og hvor: en køber i et indlejret butiksvindue, en godkendt leverandør, en virksomhedsanvender eller en assistent med udtrykkelig autorisation.

Bekræft adgangsgrænsen

Brug offentlige kontrakter til evaluering og klientgenerering, og bekræft derefter legitimationsoplysninger, scopes, miljøer, callbacks og beskyttede endpoints inden implementering.

Bevis kontinuitet i tilstand

Test at designs, tilbud, godkendelser, fejl og ordreoverleveringer forbliver versionsaktuelle på tværs af integrationen, inklusive retry- og rollback-scenarier.

Hvad enhver integration skal bevare

Én versioneret tilstand

Design, kommerciel hensigt, leverandørbacked tilbud, godkendelse og ordrestatus forbliver forbundet. Forældede ændringer skal udløse en synlig genberegning af tilbud eller en gennemgangstilstand.

Kommerciel og leverandørfortrolighed

MerchandAise forbliver den købervendte handels- og supportansvarlige. Leverandørers identiteter, kontakter og interne data eksponeres ikke gennem offentlige integrationer.

Godkendelse før produktion

En produkt-native 3D-visualisering og digitalt proof understøtter beslutningen, men de erstatter ikke den ægte produktprøve, der kræves før masseproduktion.

FAQ

Hvilken integrationsflade skal jeg starte med?

Betyder en offentlig kontrakt offentlig produktionsadgang?

Kan en integration eksponere leverandører eller omgå godkendelser?