MerchandAise izstrādātāju platforma

Viena produkta darbplūsma. Četri savienojuma veidi.

Savienojiet savu vietni, kopienu, piegādātāja operācijas vai uzņēmuma darba vidi ar vienotu, versionētu dizaina, cenu piedāvājuma, apstiprinājuma un pasūtījuma stāvokli. Sāciet ar publicēto līgumu, pēc tam plānojiet piekļuvi un ražošanas ieviešanu kopā ar mums.

Saglabājiet vienu patiesības avotu

Integrācijai ir jāpapildina MerchandAise darbplūsma, nevis tā jāaizstāj. Vietnes, iegultajiem elementiem, piegādātāja, uzņēmuma un nākotnes palīgrīku saskarnēm ir jānolasa un jāatjaunina viens un tas pats versionētais dizaina, komercnodoma, piedāvājuma, apstiprinājuma un pasūtījuma stāvoklis.

Kamēr MerchandAise apstrādā pircēja darījumu, Hutter Products GmbH ir līgumslēdzēja puse un tirgotājs (Merchant of Record) ar MerchandAise zīmolu. Piegādātāja identitāte un kontaktinformācija paliek privāta, ja vien normatīvie akti neparedz citādi, un ražošanai joprojām ir nepieciešams digitālais paraugs un īsts fiziskais paraugs.

01 — Līgumi

API un integrācijas saskarnes

Palīgrīku API dokumentācija

Izpētiet pašreizējos palīgrīku un rīku galapunktus dizaina sesijām un integrācijas pārskatīšanai. Šī publiskā atsauce nepiešķir anonīmas tiesības sagatavot cenu piedāvājumu vai veikt pasūtījumu.

Piekļuve: public

Ieviešanas ceļvedis

Atvērt palīgrīku dokumentāciju

Mašīnlasāms līgums

Palīgrīku OpenAPI JSON

/api/docs/openapi.json

Publiska atsauce palīgrīku un rīku API. Ražošanas piekļuvei un pasūtījumu operācijām joprojām ir nepieciešama atbilstoša autorizācija.

Kopienas iegultais API

Savienojiet lokalizētas kluba, kopienas vai veikala vides ar MerchandAise piederošiem dizaina un tirdzniecības procesiem, nepārbūvējot pamata darbplūsmu.

Piekļuve: public

Mašīnlasāms līgums

Kopienas OpenAPI JSON

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

Publisks versionēts līgums veikalu iegulšanai, kopienas atklāšanai un lokalizētai datu apmaiņai.

Piegādātāju API

Savienojiet apstiprinātus piegādātājus ar onboarding, kataloga, piedāvājumu un izpildes operācijām pēc tam, kad piegādātāja attiecības un piekļuves modelis ir kvalificēti.

Piekļuve: public

Mašīnlasāms līgums

Piegādātāja OpenAPI JSON

/api/v1/supplier/openapi/v1

Publisks līgums plānošanai un klienta koda ģenerēšanai. Operacionālā piegādātāja piekļuve ir balstīta uz atļaujām.

Uzņēmuma identitātes API

Plānojiet SSO, SCIM nodrošināšanu un auditam gatavas identitātes plūsmas apstiprinātām uzņēmumu merchandise programmām un kontrolētai ieviešanai.

Piekļuve: protected

Mašīnlasāms līgums

Uzņēmuma identitātes OpenAPI JSON

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

Aizsargāts līgums apstiprinātām uzņēmuma darba vidēm; pirms šī galapunkta izmantošanas pieprasiet piekļuvi.

02 — Ieviešanas ceļvedis

Izvēlieties līgumu pirms koda rakstīšanas

01
Kartējiet lietotāja ceļu
Izlemiet, kas un kur ienāk darbplūsmas: pircējs iegultā veikalā, apstiprināts piegādātājs, uzņēmuma lietotājs vai palīgrīks, kas darbojas ar nepārprotamu pilnvarojumu.
02
Apstipriniet piekļuves robežas
Izmantojiet publiskos līgumus novērtēšanai un klienta koda ģenerēšanai, pēc tam pirms ieviešanas apstipriniet piekļuves datus, tvērumus, vides, atzvanīšanas adreses (callbacks) un aizsargātos galapunktus.
03
Pārbaudiet stāvokļa nepārtrauktību
Pārbaudiet, vai dizaini, piedāvājumi, apstiprinājumi, kļūdas un pasūtījumu nodošana saglabā aktuālo versiju visā integrācijā, tostarp atkārtotas mēģinājumu (retry) un atcelšanas plūsmas.

03 — Kas jānodrošina katrā integrācijā

Kas jānodrošina katrā integrācijā

Viens versionēts stāvoklis

Dizains, komercnodoms, piegādātāja nodrošināts piedāvājums, apstiprinājums un pasūtījuma statuss paliek savienoti. Novecojušām izmaiņām ir jāaktivizē redzams jauns cenu piedāvājums vai pārskatīšanas stāvoklis.

Komerciālā un piegādātāja privātums

MerchandAise joprojām ir pircēja pusei redzamais tirgotājs un atbalsta sniedzējs. Piegādātāju identitātes, kontakti un iekšējie dati netiek atklāti, izmantojot publiskās integrācijas.

Apstiprinājums pirms ražošanas

Produktam raksturīgs 3D skats un digitālais paraugs atbalsta lēmumu pieņemšanu, taču tie neaizstāj īstu ražošanas paraugu, kas nepieciešams pirms masveida ražošanas sākšanas.

Pirms ražošanas datplūsmas

Publicēts OpenAPI fails ir plānošanas rīks, nevis solījums par anonīmu ražošanas piekļuvi. Pirms palaišanas dzīvajā vidē mēs pārbaudām vides, piekļuves datus, kļūdu apstrādi un operacionālo atbildību.

Piekļuve un vides

Apstipriniet līguma versiju, apstiprināto darba vidi, autentifikācijas tvērumus, smilšu kasti (sandbox), ražošanas akreditācijas datus un atzvanīšanas galamērķus.

Kļūdas un atkopšana

Pirms izlaišanas definējiet atkārtotus mēģinājumus, idempotenci, noildzes, klientam redzamas kļūdas, novērojamību, atbalsta atbildību un atcelšanas mehānismus.

Gala pierādījumi

Pārbaudiet paredzēto ceļu testa vidē (staging) no ienākšanas un stāvokļa maiņas līdz piedāvājumam, apstiprinājumam, nodošanai un atkopšanas darbībām.

Bieži uzdotie jautājumi

Ar kuru integrācijas saskarni man vajadzētu sākt?

Sāciet ar lietotāju un stāvokļa maiņu. Izmantojiet kopienas iegultos elementus pircēju klubam vai kopienas plūsmām, piegādātāju operācijas apstiprinātām piegādes puses darbplūsmām, uzņēmuma identitāti SSO un SCIM, un palīgrīkus tikai skaidri pilnvarotām AI vadītām plūsmām.

Vai publisks līgums nozīmē publisku piekļuvi ražošanai?

Nē. Publisks OpenAPI līgums atbalsta atklāšanu, arhitektūras pārskatīšanu un klienta koda ģenerēšanu. Ražošanas piekļuves dati, rakstīšanas operācijas, piegādātāju darbplūsmas, uzņēmuma identitāte un palīgrīku izpilde joprojām var pieprasīt apstiprinātu darba vidi un ierobežotas piekļuves autorizāciju.

Vai integrācija var atklāt piegādātājus vai apiet apstiprinājumus?

Nē. Piegādātāja identitāte un kontaktinformācija paliek privāta, ja vien atklāšana nav obligāti nepieciešama, MerchandAise ir atbildīgs par attiecībām ar pircēju, un darbībām, kas ietekmē pasūtījumu, ir jānodrošina konfigurētie apstiprinājumi un īsta parauga pārbaudes punkti.

Atnesiet mums darbplūsmu, nevis gatavu arhitektūru.

Pastāstiet mums, kurš izmantos integrāciju, kādu stāvokli viņiem nepieciešams nolasīt vai mainīt un kur atradīsies lietotāja pieredze. Mēs kopā izveidosim līguma kartējumu, piekļuves modeli un drošāko ieviešanas ceļu.

Plānot integrāciju Izpētīt AI aģentus un MCP

Saglabājiet vienu patiesības avotu

Izvēlieties līgumu pirms koda rakstīšanas

Kartējiet lietotāja ceļu

Izlemiet, kas un kur ienāk darbplūsmas: pircējs iegultā veikalā, apstiprināts piegādātājs, uzņēmuma lietotājs vai palīgrīks, kas darbojas ar nepārprotamu pilnvarojumu.

Apstipriniet piekļuves robežas

Izmantojiet publiskos līgumus novērtēšanai un klienta koda ģenerēšanai, pēc tam pirms ieviešanas apstipriniet piekļuves datus, tvērumus, vides, atzvanīšanas adreses (callbacks) un aizsargātos galapunktus.

Pārbaudiet stāvokļa nepārtrauktību

Pārbaudiet, vai dizaini, piedāvājumi, apstiprinājumi, kļūdas un pasūtījumu nodošana saglabā aktuālo versiju visā integrācijā, tostarp atkārtotas mēģinājumu (retry) un atcelšanas plūsmas.

Kas jānodrošina katrā integrācijā

Viens versionēts stāvoklis

Komerciālā un piegādātāja privātums

MerchandAise joprojām ir pircēja pusei redzamais tirgotājs un atbalsta sniedzējs. Piegādātāju identitātes, kontakti un iekšējie dati netiek atklāti, izmantojot publiskās integrācijas.

Apstiprinājums pirms ražošanas

Produktam raksturīgs 3D skats un digitālais paraugs atbalsta lēmumu pieņemšanu, taču tie neaizstāj īstu ražošanas paraugu, kas nepieciešams pirms masveida ražošanas sākšanas.

Bieži uzdotie jautājumi

Ar kuru integrācijas saskarni man vajadzētu sākt?

Vai publisks līgums nozīmē publisku piekļuvi ražošanai?

Vai integrācija var atklāt piegādātājus vai apiet apstiprinājumus?