POST/api/public/contact
Fomu ya umma ya mawasiliano ya tovuti ya Zentor. Huunda ombi katika mfumo wa ndani wa leads.
`POST /api/public/contact` huchakata fomu ya umma ya mawasiliano ya tovuti ya Zentor na kuweka ombi katika mfumo wa ndani wa leads. Endpoint haihitaji uthibitishaji wa dashboard na si idempotent. Kila utumaji uliofanikiwa unaweza kuunda lead mpya. Kwa hiyo Frontend inapaswa kuzima kitufe cha kutuma baada ya kubofya mara ya kwanza na isianzishe marudio ya kiotomatiki. Sehemu za lazima zilizothibitishwa ni `name`, `email` na `message`. Jina lazima liwe na urefu wa herufi 2 hadi 120, anwani ya barua pepe lazima iwe na muundo halali, na ujumbe lazima utimize kanuni za uthibitishaji za upande wa seva. Sehemu nyingine zinaweza kutumwa tu ikiwa zimekusudiwa katika Schema halisi. Thamani zisizojulikana hazipaswi kutumika kudhibiti sifa za ndani za lead. Fomu sahihi hukagua sehemu za lazima tayari katika kivinjari, lakini haitegemei ukaguzi huo pekee. Seva inabaki kuwa ya maamuzi. Kukiwa na hitilafu ya uthibitishaji, kiolesura kinapaswa kuweka alama kwenye sehemu husika na kuhifadhi maudhui yaliyoingizwa. Ujumbe wa jumla wa mafanikio unapaswa kuonekana tu baada ya jibu chanya la seva. Fomu ya mawasiliano si chaneli salama kwa nenosiri, API-Keys, Widget-Tokens, data za malipo au rekodi kamili za wateja. Watumiaji wanapaswa kutaja matumizi, bidhaa husika na anwani ya barua pepe ya kibiashara inayofikika. Kwa tatizo la kiufundi, jina la mpangaji, wakati, kipengele kilichoathiriwa na hatua zinazoweza kurudiwa husaidia, bila kuhamisha maudhui ya data binafsi yasiyo ya lazima. Mtiririko halisi: Mgeni anajaza jina, barua pepe na ujumbe, akithibitisha inapohitajika taarifa za ulinzi wa data za ukurasa, na kutuma fomu. Seva huthibitisha data, huunda lead na kutoa jibu la mafanikio. Kwa barua pepe isiyo halali au jina fupi mno, lead kamili haiundwi. Endpoint haiundi mpangaji, hainunui kifurushi na si mbadala wa usanidi uliopangwa wa bidhaa au mchakato wa ushauri. Ili kulinda dhidi ya spam na maombi ya mfululizo ya kiotomatiki, Client inapaswa kuheshimu hitilafu za upande wa seva na isianzishe mizunguko isiyoisha mara moja. Jibu la mafanikio linapaswa kufuta sehemu za kuingiza tu baada ya seva kuthibitisha kupokea. Jibu lisipokuja, mtumiaji anaweza kuhifadhi maudhui na kutuma tena baadaye kwa udhibiti. Kwa upangaji wa ndani, ujumbe unapaswa kuwa na sababu halisi, bila maneno ya masoko wala viambatisho vya siri. Mada iliyo wazi na maelezo sahihi ya tatizo hupunguza maswali ya ziada. Hata hivyo API yenyewe haitoi kipaumbele kilichohakikishwa na haithibitishi muda maalum wa ushughulikiaji.
Uthibitishaji na ulinzi
Hakuna uthibitishaji unaohitajika
Idempotent: Hapana
Vigezo
name(body, string, inahitajika)— Herufi 2–120email(body, string, inahitajika)— Barua pepe sahihimessage(body, string, inahitajika)— Herufi 10–3000company(body, string)phone(body, string)topic(body, string)consentGiven(body, boolean, inahitajika)— Lazima iwe true (idhini ya ulinzi wa data)Mfano wa ombi (request)
{"name":"Max Mustermann","email":"max@example.com","message":"Ujumbe wako (angalau herufi 10).","consentGiven":true}Mfano wa jibu (response)
{"ok":true,"message":"Ombi lako limetumwa."}Misimbo ya hitilafu
400 VALIDATION_ERROR — Sehemu ya lazima haipo/si halali, au idhini ya ulinzi wa data haipo (Details-Array yenye ujumbe wa hitilafu mmoja mmoja).Uthibitisho wa jaribio la moja kwa moja
Mafanikio (200) na kesi hasi (400, sehemu zinazokosekana ikiwemo idhini inayokosekana) yamethibitishwa moja kwa moja (live).