Tuma na pokea WhatsApp kutoka Node.js
Kupokea ni route inayojibu GET ya uthibitishaji ya Meta na kukubali POSTs. Kutuma ni fetch call kwa Cloud API yenye phone number id na token ya nambari. Hatuna SDK yetu wala kitu cha kusakinisha.
GET kwa uthibitishaji wa Meta na POST kwa matukio.
Dirisha la saa 24 baada ya ujumbe wa mteja ambapo maandishi ya kawaida yanaweza kutumwa.
Hitilafu inayorejeshwa unapotuma maandishi ya kawaida nje ya dirisha hilo.
Unapokeaje jumbe kwenye Node?
Route moja yenye mbinu mbili, katika Express, Fastify, Next route handler au server ya kawaida.
GET hujibu uthibitishaji wa Meta: soma hub.mode, hub.verify_token na hub.challenge kutoka query, linganisha token na yako, kisha rudisha challenge kama maandishi ghafi. Kuirejesha kama JSON ni kosa la kawaida na hutengeneza endpoint ambayo haipokei chochote, ingawa inaonekana sahihi.
POST hupokea matukio. Jibu 200 mara moja, kisha uchakate. Meta hurudia ombi lolote linalochelewa, na handler inayofanya kazi kabla ya kujibu itaona ujumbe uleule zaidi ya mara moja. Kwenye serverless hasa, kujibu kwanza na kuweka kazi kwenye foleni huzuia cold start kugeuka kuwa nakala mbili.
Unatumaje?
Fetch kwa Cloud API messages endpoint ya phone number id, ikiwa na token kama bearer header.
Hakuna kitu hapa kinachotegemea sisi, hivyo ombi linafanana kabisa na nyaraka za Meta na hakuna wrapper ya kujifunza au kufungiwa nayo. Thamani zote mbili ziko kwenye dashboard, na get_api_credentials huzirejesha kupitia MCP connector ikiwa assistant anafanya muunganisho.
Mwili wa ombi hutegemea muda. Ndani ya saa 24 tangu ujumbe wa mwisho wa mteja uliopokelewa, tuma text object. Nje ya hapo, tuma template object yenye jina la template lililoidhinishwa na lugha. Code inayotuma maandishi pekee hupita kila jaribio, kisha hushindwa ujumbe wa kwanza unaowasili usiku.
Kuna tofauti gani kwenye serverless?
Kuna mambo mawili, na yote yanahusu function kumalizika kabla kazi haijaisha.
Kurejesha 200 kisha kuendelea kuchakata hakudumu kwenye function inayoganda mara tu inapojibu. Tumia kile ambacho platform yako hutoa ili kazi iendelee baada ya jibu, au sukuma payload kwenye queue na uache function tofauti ishughulikie. Meta inahitaji acknowledgement haraka tu, haihitaji kazi ikamilike.
Cold starts pia hufanya majibu ya polepole yawe na uwezekano mkubwa, jambo linalomaanisha retries zaidi na nakala zaidi. Deduplicating kwa kutumia wamid message id si hiari katika muundo huu, ndilo linaloufanya uwe wa kuaminika.
Makosa ya kawaida
- Kurejesha challenge kama JSON badala ya body ghafi.
- Kufanya kazi kabla ya kujibu 200. Kwenye serverless function inaweza kuganda mara tu inapojibu.
- Kuruka deduplication. Meta hurudia kwa makusudi na nakala ni za kawaida, si hali ya nadra.
Unganisha nambari kwenye easycoexistence.com, weka webhook destination kwenye route yako, kisha soma phone number id na token kutoka dashboard. Kuanzia US$ 9 kwa kila nambari kwa mwezi, hadi US$ 2 kwa idadi kubwa, na siku 7 za kwanza bila malipo.
Maswali yanayoulizwa mara kwa mara
Je, nahitaji library?
Hapana. Route na fetch vinatosha, na ombi linafanana kabisa na nyaraka za Meta.
Je, hii inafanya kazi kwenye Vercel au Lambda?
Ndiyo, kwa tahadhari ya kawaida ya serverless: kubali kwanza, kisha chakata kupitia queue au utaratibu wa nyuma badala ya inline.
Ninathibitishaje kuwa ombi limetoka Meta?
Kagua signature header dhidi ya app secret yako. Ni vyema kufanya hivyo mara tu endpoint inapowekwa wazi.
Je, naweza kutumia TypeScript?
Ndiyo. Hakuna kitu cha kuandikia aina kutoka kwetu, kwa kuwa payload ni ya Meta na imeandikwa na Meta.
Endelea kusoma
Uko tayari kuanza?
Sanidi WhatsApp Coexistence kwa dakika chache, si miezi. Programu inaendelea kufanya kazi kwenye simu.
Anza kipindi cha majaribio bila malipoImethibitishwa kwenye