Discord webhook-ები თამაშის სერვერის სტატუსისა და შეტყობინებებისთვის

Discord webhook არის URL, რომელიც HTTP POST-ს ერთ არხში შეტყობინებად აქცევს. არც bot არის საჭირო, არც token, არც gateway კავშირი და არც შესვლა: არხის პარამეტრებში ქმნი URL-ს, მასზე JSON-ს POST-ავ და შეტყობინება ჩნდება. სერვერის სტატუსისთვის, restart-ის შეტყობინებებისთვის, backup-ის დადასტურებებისა და "Minecraft სერვერი ისევ ჩაირთო"-სთვის სწორედ ეს არის მთელი მექანიზმი და მისი გამართვა დაახლოებით ოთხ წუთს ითხოვს.

ის ნაწილები, რომლებზეც ხალხი მოგვიანებით ცდება, ცოდნის ღირსია. Webhook მხოლოდ წერას შეძლებს, ამიტომ ყველაფერს, რაც ჩატის წაკითხვას ან ბრძანებაზე პასუხს ითხოვს, ნამდვილი bot სჭირდება. ყოველ წუთში შეტყობინების გაგზავნა არხს ხმაურით ავსებს, რომელსაც არავინ კითხულობს; იმავე შეტყობინების რედაქტირება ერთ ცოცხალ სტატუს-ხაზს ინახავს. Discord webhook-ებს rate-limit-ს უწესებს და გიბრუნებს 429-ს ზუსტად იმ წამების რაოდენობით, რამდენიც უნდა დაელოდო, რასაც სახლში დაწერილი სკრიპტების უმეტესობა უგულებელყოფს. და URL credential-ია - ვინც მას ფლობს, შეუძლია შენი სერვერის სახელით დაწეროს, სამუდამოდ, სანამ webhook-ს არ წაშლი.

რა არის webhook და რას ვერ აკეთებს#

Webhook არხს ეკუთვნის და არა შენ. მას აქვს id და token და ორივე ერთად არის მთელი URL:

https://discord.com/api/webhooks/1234567890123456789/aBcD...token

სხვა ავთენტიფიკაცია არ არსებობს. ეს URL არის credential და ის ერთადერთი credential-ია. ვისაც ის აქვს, შეუძლია ამ არხში ამ webhook-ის სახელით დაწეროს, ნებისმიერი სახელითა და ავატარით, სანამ ვინმე webhook-ს არ წაშლის.

რას აკეთებს webhook:

• იმ ერთ არხში აგზავნის შეტყობინებას content-ით, embed-ებით, ფაილებით ან სამივეთი.
• თითო შეტყობინებაზე გადაფარავს ჩვენებულ სახელსა და ავატარს, ამიტომ ერთ webhook-ს შეუძლია დაწეროს როგორც "Survival" და როგორც "Lobby".
• წერს ამ არხის thread-ში thread_id query პარამეტრით.
• ცვლის და შლის შეტყობინებებს, რომლებიც მან თვითონ გააგზავნა.

რას ვერ აკეთებს:

• ვერაფერს კითხულობს. არც ჩატს, არც რეაქციებს, არც წევრების სიას.
• ვერ პასუხობს slash ბრძანებას, ღილაკს ან mention-ს.
• ვერ წერს სხვაგან, გარდა საკუთარი არხისა.
• ვერ ანიჭებს როლებს, ვერ აგდებს, ვერ ban-ავს და ვერ აკეთებს იმას, რასაც ადმინისტრატორი აკეთებს.

ეს სია მთელი გადაწყვეტილებაა. ცალმხრივი შეტყობინებები webhook-ია. ნებისმიერი ორმხრივი რამ bot-ია token-ით, gateway კავშირითა და intents კონფიგურაციით, რაც სხვა პროგრამაა სხვა ჰოსტინგის მოთხოვნებით - Discord bot-ის ჰოსტინგი 24/7 ამ მხარეს ფარავს, ხოლო გეგმის არჩევა Discord bot-ისთვის გვიჩვენებს, რა ღირს მისი ონლაინ შენარჩუნება.

შექმნა და პირველი შეტყობინება#

Discord-ში: დააწკაპუნე არხზე მარჯვენა ღილაკით, Edit Channel, Integrations, Webhooks, New Webhook. დაარქვი სერვერის სახელი, რომელზეც ის იტყობინება, და არა "Webhook 1", რადგან ეს სახელი ნაგულისხმევად შეტყობინების ავტორად ჩნდება. დააკოპირე URL. არხს შეუძლია 15 webhook-მდე ჰქონდეს, რაც ყოველი სერვერისთვის საკუთარის მისაცემად ბევრად მეტია.

ყველაზე მარტივი შესაძლო შეტყობინება:

$ curl -X POST "$WEBHOOK_URL" \    -H "Content-Type: application/json" \    -d '{"content": "Survival server is back up."}'

წარმატებული გაგზავნა აბრუნებს 204 No Content-ს და ცარიელ სხეულს. თუ შეტყობინების დაბრუნება გინდა - კერძოდ მისი id, რომ მოგვიანებით დაარედაქტირო - დაამატე ?wait=true და მიიღებ 200-ს შეტყობინების სრული ობიექტით:

$ curl -X POST "$WEBHOOK_URL?wait=true" \    -H "Content-Type: application/json" \    -d '{"content": "Restarting for updates in 5 minutes."}'

თითქმის ყოველ ავტომატურ შეტყობინებაზე ორი ფლაგის დაყენება ღირს. allowed_mentions ცარიელი parse მასივით ხელს უშლის ლოგის ხაზს, რომელშიც შემთხვევით @everyone წერია, ექვსასი ადამიანის შეწუხებაში - ეს console bridge-ის კლასიკური უბედური შემთხვევაა. და flags: 4096 თიშავს ბმულების preview-ს, რათა URL-ის შემცველმა შეტყობინებამ არხში არასასურველი ბარათი არ ჩამოიტანოს.

{  "username": "Survival",  "content": "Backup finished: 412 MB in 38s",  "allowed_mentions": { "parse": [] },  "flags": 4096}

Embed-ები: JSON, რომელიც წასაკითხს ხდის#

ერთხაზიანი შეტყობინებისთვის უბრალო content კარგია. სტატუს პანელისთვის embed გინდა: ჩარჩოიანი ბარათი ფერადი ზოლით, სათაურით, სვეტებად განლაგებული ველებით და დროის ნიშნულით. სტრუქტურა ფიქსირებულია და ლიმიტები რეალურია.

{  "username": "Valheim",  "embeds": [    {      "title": "Longship Crew",      "description": "Online - world saved 4 minutes ago",      "color": 3066993,      "fields": [        { "name": "Players", "value": "3 / 10", "inline": true },        { "name": "Version", "value": "0.220.5", "inline": true },        { "name": "Uptime", "value": "6d 4h", "inline": true }      ],      "footer": { "text": "checked every 60s" },      "timestamp": "2026-09-21T14:03:00.000Z"    }  ],  "allowed_mentions": { "parse": [] }}

რაზეც ხალხი ებმევა:

• `color` ათობითი მთელი რიცხვია და არა hex სტრიქონი. 0x2ECC71 არის 3066993. აქ სტრიქონი 400-ს იძლევა.
• `timestamp` ISO 8601 უნდა იყოს. Discord მას ყოველი მნახველის ადგილობრივ დროში აჩვენებს, რაც სტატუს-შეტყობინებისთვის embed-ის გამოყენების ერთადერთი საუკეთესო მიზეზია - არავის არ უწევს შენი დროის სარტყლის გარკვევა.
• `inline: true` ველებს გვერდიგვერდ აწყობს, დესკტოპზე სამს ერთ რიგში და მობილურზე ნაკლებს. Inline და არა-inline ველების შერევა გაუთვალისწინებელ განლაგებებს იძლევა, ამიტომ თითო სექციაში ერთი აირჩიე.

მკაცრი ლიმიტები, რომლებიც ამოჭრის ნაცვლად 400-ს აბრუნებს:

6000 სიმბოლოს ჯამური ლიმიტი console bridge-ს აზიანებს. description-ში ჩასმული გრძელი stack trace ჩვეულებრივი მუშაობისას ჩუმად აჭარბებს მას და ჩავარდება იმ ინციდენტის დროს, რისთვისაც bridge ააგე. შეკვეცე ფიქსირებულ სიგრძეზე შენს მხარეს და სრული ტექსტი ისეთ ადგილას ჩააგდე, რომელიც სრულ ტექსტს ინახავს - იხილე ლოგები, რომლებსაც ღირს შენახვა.

ორი თავსებადობის მალსახმობი არსებობს და მართლაც სასარგებლოა. webhook URL-ზე /slack-ის მიმატება Slack ფორმატის payload-ს იღებს, /github კი GitHub-ისას. ეს ნიშნავს, რომ ხელსაწყოს, რომელმაც მხოლოდ Slack-თან საუბარი იცის - monitoring სისტემა, CI runner - Discord-ში ადაპტერის გარეშე შეუძლია გაგზავნა. მიუთითე ის https://discord.com/api/webhooks/ID/TOKEN/slack-ზე და ის იმუშავებს.

ერთი დარედაქტირებული შეტყობინება ასი გაგზავნის ნაცვლად#

სტატუს webhook-ის ნაგულისხმევი დიზაინი ყოველ წუთს გაგზავნაა. დღის შემდეგ ეს 1 440 შეტყობინებაა, არხი წაუკითხავია და ყველა, ვისაც შეტყობინებები ჩართული აქვს, მას ხმას უთიშავს. უკეთესი დიზაინი ერთი შეტყობინებაა, რომელიც ადგილზე რედაქტირდება.

გააგზავნე ერთხელ ?wait=true-ით, შეინახე დაბრუნებული id, შემდეგ მას PATCH-ი გაუკეთე:

# First run: create and remember the id$ MESSAGE_ID=$(curl -s -X POST "$WEBHOOK_URL?wait=true" \    -H "Content-Type: application/json" \    -d @status.json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])")# Every run after that: edit the same message$ curl -s -X PATCH "$WEBHOOK_URL/messages/$MESSAGE_ID" \    -H "Content-Type: application/json" \    -d @status.json

შეტყობინების id შეინახე ისეთ ადგილას, რომელიც restart-ს გადარჩება - სკრიპტის გვერდით ფაილი საკმარისია. თუ id დაიკარგა ან შეტყობინება წაიშალა, PATCH აბრუნებს 404-ს და ახალს აგზავნი. ეს არის მთელი მდგომარეობის მანქანა:

1. წაიკითხე შენახული შეტყობინების id. თუ არ არის, გადადი მე-4 ნაბიჯზე.
2. PATCH-ი გაუკეთე შეტყობინებას ახალი სტატუსით.
3. თუ პასუხია 404, დაივიწყე id და გადადი მე-4 ნაბიჯზე. სხვა შემთხვევაში გაჩერდი.
4. POST ?wait=true-ით, შეინახე დაბრუნებული id, გაჩერდი.

დარედაქტირებული შეტყობინება არავის აფრთხილებს, რაც ზუსტად სწორია სტატუს-ხაზისთვის, რომელიც ყოველ წუთს იცვლება. შეინახე მეორე webhook, სხვა არხში, იმ მოვლენებისთვის, რომლებმაც უნდა გააფრთხილოს: სერვერი გაითიშა, backup ჩავარდა, დისკი თითქმის გაივსო. მდგომარეობისთვის რედაქტირება, მოვლენებისთვის გაგზავნა, განსხვავებაა, რომელიც ხალხს არხის ხმის ჩართულად ტოვებინებს.

Rate limit-ები, 429 და retry, რომელსაც უნდა დაემორჩილო#

Discord ყოველ route-ს rate-limit-ს უწესებს. Webhook-ისთვის პრაქტიკული მაჩვენებლებია დაახლოებით ხუთი მოთხოვნა ყოველ ორ წამში თითო webhook-ზე და დაახლოებით ოცდაათი შეტყობინება წუთში ერთ არხში. ეს რიცხვები სახელშეკრულებო არ არის და Discord მათ ცვლის, ამიტომ ისინი sleep-ად ნუ ჩაწერ და საქმე დასრულებულად ნუ ჩათვლი. მის ნაცვლად პასუხს გაუმკლავდი.

ლიმიტს რომ გადააჭარბებ, იღებ 429-ს JSON სხეულითა და header-ებით:

HTTP/1.1 429 Too Many RequestsX-RateLimit-Limit: 5X-RateLimit-Remaining: 0X-RateLimit-Reset-After: 0.529Retry-After: 1{"message": "You are being rate limited.", "retry_after": 0.529, "global": false}

სხეულში retry_after წამებია float-ის სახით და ის ავტორიტეტული რიცხვია. იმდენ ხანს დაიძინე და ერთხელ სცადე თავიდან. თუ global არის true, მიაღწიე ანგარიშის მასშტაბის ლიმიტს - 50 მოთხოვნა წამში - და გაქვს უფრო დიდი პრობლემა, ვიდრე ეს ერთი შეტყობინებაა.

სამი წესი, რომელიც webhook-ს სამუდამოდ უსაფრთხოდ ინახავს:

• არასოდეს გაიმეორო მოთხოვნა მჭიდრო ციკლში. სკრიპტი, რომელიც 429-ზე მაშინვე იმეორებს, ნახევარი წამის დაყოვნებას მდგრად წყალდიდობად აქცევს და შეიძლება webhook გამოირთოს.
• დააჯგუფე. ათი ლოგის ხაზი ერთ შეტყობინებაში ახალი ხაზებით ერთი მოთხოვნაა. ათი შეტყობინება ათია. Console bridge-მა ერთი-ორი წამი უნდა დააგროვოს და ნაკრები გააგზავნოს.
• `5xx`-ზეც უკან დაიხიე. Discord დატვირთვისას 500-სა და 502-ს აბრუნებს. ექსპონენციალური backoff ზღვრით, შემდეგ დანებება და ლოკალურად ჩაწერა. Monitoring სისტემა, რომელიც იმიტომ ვარდება, რომ მისი შეტყობინების არხი დატვირთულია, უარესია, ვიდრე monitoring საერთოდ არ იყოს.

საიდან მოდის სტატუსი: თამაშის სერვერის poll-ინგი#

Webhook ადვილი ნახევარია. ვინმემ უნდა იცოდეს, რამდენი მოთამაშეა ონლაინ, და ეს ვიღაც თავად თამაშის სერვერისთვის გაგზავნილი query-ა.

ყველა ამისთვის ბიბლიოთეკები არსებობს და საკუთარი A2S parser-ის წერა საღამოს კარგი გამოყენება არ არის. უფრო მნიშვნელოვანია, სად მუშაობს poller. ის ვერ იმუშავებს იმ თამაშის სერვერზე, რომელსაც უყურებს, რადგან საინტერესო შემთხვევა სწორედ სერვერის გათიშვაა. ის უნდა იყოს ცალკე, პატარა, ყოველთვის ჩართული პროცესი.

თამაშის სერვერის გეგმაზე დაგეგმილი ამოცანა კონსოლის ბრძანებებს, backup-ებსა და ჩართვა-გამორთვის მოქმედებებს უშვებს - HTTP მოთხოვნის გაგზავნა არ შეუძლია. ამიტომ poller იქ უნდა იყოს, სადაც შენს საკუთარ კოდს უშვებ: Node ან Python app გეგმაზე, VDS-ზე ან უკვე არსებულ მანქანაზე. RE:NODE-ზე app გეგმები თვეში $4-დან იწყება და იგივე panel-ს, კონსოლსა და GitHub-იდან deploy-ს გაძლევს, რაც ორმოცდაათხაზიანი სკრიპტისთვის ტაიმერზე საკმარისია. მიმდინარე გეგმებისთვის იხილე app ჰოსტინგის გვერდი, ხოლო იმისთვის, რა სიპატარავეა უსაფრთხო, გეგმის არჩევა Discord bot-ისთვის.

სკრიპტის ფორმა ნებისმიერ ენაზე ერთნაირია:

import json, os, urllib.requestdef post(payload, url=os.environ["WEBHOOK_URL"]):    body = json.dumps(payload).encode()    req = urllib.request.Request(        url, data=body, headers={"Content-Type": "application/json"}    )    with urllib.request.urlopen(req) as res:        return res.status

Poll-ი ფიქსირებული ინტერვალით, შედარე შედეგი წინასთან, სტატუს-შეტყობინება ყოველ ჯერზე დაარედაქტირე და შეტყობინებების არხში გააგზავნე მხოლოდ მაშინ, როცა მდგომარეობა შეიცვალა. ეს ბოლო პირობა არის განსხვავება სასარგებლო არხსა და დადუმებულს შორის. Monitoring, რომელიც რამეს გეუბნება ამის ასე აგების უფრო გრძელი არგუმენტია.

Console bridge-ები, plugin-ები და როდის გჭირდება ნამდვილი bot#

ხალხი ზემოთ აღწერილიდან არაფერს წერს, რადგან plugin უკვე არსებობს.

• Minecraft. DiscordSRV არის დამკვიდრებული ჩატის bridge. ის თავისი ძირითადი ფუნქციისთვის webhook-ის ნაცვლად bot token-ს იყენებს - რადგან Discord-ის შეტყობინებები უნდა წაიკითხოს და თამაშის ჩატში ჩააგდოს, რასაც webhook ვერ აკეთებს - და შემდეგ webhook-ებს შიგნით იყენებს, რომ თამაშში მყოფი მოთამაშეები საკუთარი სახელებითა და skin-ებით გამოჩნდნენ. ეს ჰიბრიდი არის მიზეზი, რატომ სჭირდება ორივე.
• FiveM. რესურსები, რომლებიც შესვლებს, გასვლებს, ban-ებსა და ადმინის მოქმედებებს webhook-ში აგზავნის, სტანდარტულია და txAdmin-საც შეუძლია Discord-ში ანგარიშგება. FiveM და txAdmin გამართვას აღწერს.
• Source-ის თამაშები. SourceMod plugin-ები მატჩის შედეგებსა და ადმინის მოქმედებებს webhook-ში აგზავნის.
• ნებისმიერი სხვა. ლოგის ფაილს მიჰყევი და გააგზავნე ხაზები, რომლებიც შაბლონს ემთხვევა. ეს უნივერსალური სარეზერვო გზაა, ნებისმიერ თამაშზე მუშაობს და დაახლოებით ოცი ხაზი კოდია.

Bridge-ში შერჩევითი იყავი. სრული კონსოლის გამოტანა Discord-ში ერთ დღეში წაუკითხავი ხდება და rate limit-ს განუწყვეტლივ წვავს. აირჩიე მოვლენები, რომლებიც ლოგინიდან ადგომას გაიძულებდა: სერვერი გაჩერდა, crash-ის ხაზი, მოთამაშეების რაოდენობამ ზღვარი გადაკვეთა, backup ჩავარდა. თუ შენი სერვერი იმდენად ხშირად ირესტარტება, რომ შეტყობინება ხმაურიანია, პრობლემა შეტყობინება არ არის - პრობლემა რატომ ირესტარტება შენი თამაშის სერვერი განუწყვეტლივ არის.

როცა რაიმე ქვემოთ ჩამოთვლილიდან გინდა, გჭირდება bot და არა webhook: /status ბრძანება, ღილაკი, რომელიც სერვერს რესტარტს უკეთებს, Discord ჩატის თამაშში წაკითხვა, როლის მინიჭება, როცა ვინმე ანგარიშს აკავშირებს, ან შეტყობინებაზე რეაგირება. ეს ნამდვილი აპლიკაციაა დასაცავი token-ით და შესანარჩუნებელი პროცესით.

URL პაროლივით მოექეცი და გააგზავნე წასაკითხი შეტყობინებები#

Webhook URL არის bearer credential ვადის გარეშე და არხის გარდა სხვა ფარგლების გარეშე. მოექეცი შესაბამისად.

• არასოდეს დააკომიტო. ჩააგდე environment variable-ში, წაიკითხე გაშვებისას და repository-ს მოარიდე. panel-ის Startup ტაბი environment variable-ებს სწორედ ამისთვის ინახავს. Environment variable-ები და საიდუმლოები ზოგად შემთხვევას ფარავს.
• ნუ ჩააგდებ Discord-ის შეტყობინებაში, screenshot-ში, pastebin-ში ან support ticket-ში. თუ ვინმეს შენი კონფიგის ნახვა სჭირდება, URL-ის token-ის ნახევარი დაფარე.
• შეცვალე წაშლით. Webhook-ისთვის პაროლის reset არ არსებობს. თუ ერთი გაჟონა, წაშალე არხის პარამეტრებში და შექმენი ახალი; ძველი URL მაშინვე წყვეტს მუშაობას.
• ერთი webhook ერთი დანიშნულებისთვის. ცალკე webhook-ები სტატუსისთვის, შეტყობინებებისა და console bridge-ისთვის ნიშნავს, რომ გაჟონვა ან შეცდომა ერთ არხს ეხება და პირველივე შეხედვით ხედავ, რომელი სკრიპტია ხმაურიანი.

შემდეგ დაუნდობელი იყავი იმაში, რასაც აგზავნი. შეტყობინებების მთავარი პრობლემა შეტყობინების გამოტოვება არ არის; ისაა, რომ იმდენს აგზავნი, რომ ხალხი უყურებას წყვეტს. არხი, რომელიც კვირაში ერთხელ წერს, იკითხება. არხი, რომელიც ყოველ ათ წუთში წერს, ორ კვირაში ხმადაქვეითებულია და ხმადაქვეითებული იქნება იმ ღამეს, როცა რაღაც ნამდვილად გაფუჭდება.

თამაშის სერვერისთვის კარგი ნაგულისხმევი ნაკრები: სერვერი მოულოდნელად გაჩერდა, სერვერი დაბრუნდა, backup ჩავარდა, დისკი 85 პროცენტს ზემოთაა, მოთამაშეების რაოდენობამ შენთვის მნიშვნელოვანი ზღვარი გადაკვეთა და განახლება გამოიყენა. ეს ექვსი სახის მოვლენაა და უმეტესობა იშვიათად ირთვება. ყველაფერი დანარჩენი შეიძლება ცხოვრობდეს დარედაქტირებულ სტატუს-შეტყობინებაში, სადაც ჩუმად იცვლება, ან ლოგში, სადაც წასაკითხად წახვალ, როცა მიზეზი გექნება.

FAQ#

მჭირდება bot token webhook-ის გამოსაყენებლად?

არა. Webhook URL საკუთარ token-ს შეიცავს და სხვა არაფერი სჭირდება. bot token გჭირდება მხოლოდ მაშინ, როცა რაღაცამ Discord-იდან უნდა წაიკითხოს - ორივე მიმართულებით ჩატის bridge-ები, slash ბრძანებები, ღილაკები ან როლების მართვა.

რა სიხშირით შემიძლია webhook-ზე გაგზავნა?

დაახლოებით ხუთი მოთხოვნა ყოველ ორ წამში თითო webhook-ზე და დაახლოებით ოცდაათი შეტყობინება წუთში არხზე, მაგრამ ეს ორიენტირად მიიღე. საიმედო მიდგომაა 429 პასუხის დამუშავება და იმდენი ხნით დაძინება, რამდენსაც retry_after მნიშვნელობა გეუბნება.

შემიძლია შეტყობინების განახლება ახლის გაგზავნის ნაცვლად?

დიახ. გააგზავნე ?wait=true-ით, შეინახე შეტყობინების id პასუხიდან, შემდეგ webhook URL-ს /messages/{id} დაუმატე და PATCH-ი გაუკეთე. რედაქტირება არავის აფრთხილებს, რაც მას იდეალურს ხდის ცოცხალი სტატუს-ხაზისთვის.

რატომ აფრთხილებს ჩემი webhook ყველას?

იმიტომ, რომ შეტყობინების სხეულში იყო @everyone ან როლის mention და არაფერმა ჩაახშო. გააგზავნე "allowed_mentions": {"parse": []} ყოველ ავტომატურ შეტყობინებაზე, განსაკუთრებით ყველაფერზე, რაც ჩატს ან ლოგის ტექსტს გადააგზავნის.

სად უნდა მუშაობდეს სტატუსის poller?

არა იმ სერვერზე, რომელსაც უყურებს, რადგან გჭირდება, რომ ის მუშაობდეს, როცა ის სერვერი გამორთულია. პატარა app გეგმა, VDS ან ნებისმიერი ყოველთვის ჩართული მანქანა სწორია. თამაშის სერვერის გეგმაზე დაგეგმილ ამოცანას შეუძლია კონსოლის ბრძანებებისა და backup-ების გაშვება, მაგრამ HTTP მოთხოვნის გაგზავნა არ შეუძლია.

ჩემმა webhook-მა მუშაობა შეწყვიტა. რა მოხდა?

ან წაიშალა არხის პარამეტრებში, ან არხი წაიშალა, ან URL თავიდან დაგენერირდა. ვადა არ არსებობს და rate-limit-ის ban, რომელიც გრძელდება, არც. შეამოწმე, webhook ჯერ კიდევ არსებობს თუ არა, შემდეგ შეამოწმე, მთელ URL-ს აგზავნი თუ არა token-ის ჩათვლით.