გამოიყენეთ ანგარიშის კუთვნილი შეტყობინებების ბრენდი
გამოიყენეთ გააქტიურებული API ანგარიში HTTPS კავშირით, ნებადართული საწყისი IP მისამართიდან. მხარდაჭერილია Basic და Bearer ავთენტიფიკაცია. ბრენდის იდენტიფიკატორი ამ ანგარიშს უნდა ეკუთვნოდეს. მომწოდებლის ტოკენები, ბრენდის საიდენტიფიკაციო მონაცემები და დაბრუნებული ანგარიშები კონფიდენციალურად შეინახეთ.
გამოიყენეთ მომწოდებლის არსებული შედეგი
გამოიყენეთ PUT, რათა მხარდაჭერილი მომწოდებლის არსებული შემოწმების შედეგი თქვენს ბრენდს დაუკავშიროთ. ეს ახალ შემოწმებას არ უკვეთავს. მომწოდებლის ტრანზაქციის სწორი იდენტიფიკატორი და ნებისმიერი დამადასტურებელი ტოკენი უშუალოდ ამ მომწოდებლისგან მიიღეთ და დარწმუნდით, რომ ანგარიში იმავე ბიზნესს ეკუთვნის.
AUTHPLUS იმპორტის ამ პროცესს არ უჭერს მხარს. მომწოდებლის სპეციფიკური შესაბამისობის წესები კვლავ მოქმედებს; იმპორტის მოთხოვნა მათ არ აუქმებს და კამპანიის გამოყენების ყველა შემთხვევისთვის დასაშვებობას არ იძლევა გარანტირებულად.
მოამზადეთ იმპორტი
| ველი | მნიშვნელობა |
|---|---|
| evpId | მხარდაჭერილი მომწოდებლის იდენტიფიკატორი, 1–10 სიმბოლო. |
| vettingId | მომწოდებლის შემოწმების ტრანზაქციის რეალური იდენტიფიკატორი, არაუმეტეს 255 სიმბოლოსი. მის ნაცვლად ნუ გამოიყენებთ ბრენდის იდენტიფიკატორს და ნუ მოიგონებთ იდენტიფიკატორს. |
| vettingToken | დამადასტურებელი ტოკენი, როდესაც მას მომწოდებელი მოითხოვს, არაუმეტეს 65535 სიმბოლოსი. შეინახეთ საიდუმლოდ და არ მიუთითოთ, თუ მომწოდებელი მას არ მოითხოვს. |
შექმენით vetting-import.json მომწოდებლის რეალური მნიშვნელობების გამოყენებით. ნუ გაგზავნით მხოლოდ პასუხისთვის განკუთვნილ ქულის, სტატუსის ან დროის ნიშნულის ველებს ისე, თითქოს მათ შედეგის შეცვლა შეეძლოთ.
შედეგის იმპორტი ერთხელ შეასრულეთ
curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
--request PUT \
--header 'Content-Type: application/json' \
--header "Idempotency-Key: $IDEMPOTENCY_KEY" \
--data-binary @vetting-import.json \
"https://api.multitel.net/tcr/v2/brand/$BRAND_ID/externalVetting"გაეცანით არსებულ გადასახდელებს
ეს პროქსი ახლად იმპორტირებულ შედეგს ახალ ფასიან შეკვეთად არ აღრიცხავს. ეს ადრე შეკვეთილ შემოწმებას არ აუქმებს: როდესაც იმავე vettingId იდენტიფიკატორს უკვე აქვს შედეგის ან საფასურის ჩამოჭრის მოლოდინში მყოფი შეკვეთა, ACTIVE ან FAILED შედეგის იმპორტმა შეიძლება გამოიწვიოს მისთვის შენახული საფასურის ჩამოჭრა. სინქრონიზაციის ამ განშტოებაში ჩანაწერისთვის, რომლის საფასურიც უკვე ჩამოიჭრა, თანხა ხელახლა არ ჩამოიჭრება.
თვალი ადევნეთ რეალურ შედეგს
წარმატებული HTTP პასუხი შეიძლება შეიცავდეს შემოწმების ჩანაწერს, რომელიც ჯერ კიდევ დამუშავების მოლოდინშია. შეინახეთ მისი vettingId და შეამოწმეთ vettingStatus, მიზეზები, ქულა და ძალაში შესვლის/მოქმედების ვადის გასვლის თარიღები, თუ ისინი ხელმისაწვდომია. PENDING და UNSCORE შემდგომ დაკვირვებას საჭიროებს; ACTIVE, FAILED და EXPIRED სხვადასხვა შედეგს აღწერს. მხოლოდ HTTP დონეზე მოთხოვნის მიღება ხელსაყრელ ქულას ან კამპანიისთვის დასაშვებობას არ ადასტურებს.
გამოიყენეთ გარე შემოწმების სტატუსი ჩანაწერისთვის თვალის სადევნებლად. საბოლოო შედეგის წაკითხვამ ან იმპორტმა შეიძლება გამოიწვიოს ადრე განთავსებული ფასიანი შეკვეთის საფასურის ჩამოჭრა; ეს მოქმედება აუცილებლობით არ ათავისუფლებს არსებული გადაუხდელი საფასურისგან.
ხელახლა სცადეთ იმავე განზრახული მოთხოვნის გაგზავნა
თითოეული განზრახული ოპერაციისთვის გამოიყენეთ ერთი Idempotency-Key და ზუსტად შეინარჩუნეთ მეთოდი, ბილიკი, მოთხოვნის პარამეტრები და მოთხოვნის სხეულის ბაიტები. გასაღებები შეიძლება შეიცავდეს 1–128 ბეჭდვად ASCII სიმბოლოს, გამოტოვებების გარეშე. უკვე დამუშავების პროცესში მყოფი მოთხოვნის დუბლიკატმა შეიძლება დააბრუნოს 409 და Retry-After. დასრულებული მოთხოვნების გამეორებისას ბრუნდება მათი შენახული პასუხი, შეცდომების ჩათვლით. დაიცავით მოთხოვნების სიხშირის შეზღუდვები.
მონაცემთა გადაცემის შეფერხებას შეიძლება მოჰყვეს ქეშში შენახული 502 პასუხი. ქეშში შენახული 500 პასუხი, რომელიც შეიცავს requestId, შეიძლება ნიშნავდეს, რომ რეესტრმა ოპერაცია მიიღო, მაგრამ მონაცემების ადგილობრივად მუდმივად შენახვა ან საფასურის დარიცხვა ვერ შესრულდა. შეინახეთ მოთხოვნის იდენტიფიკატორი, შეამოწმეთ მიმდინარე ჩანაწერები და ახალი გასაღების გამოყენებამდე მხარდაჭერის სამსახურთან შეაჯერეთ მდგომარეობა. ნუ ჩათვლით, რომ შეცდომა შეკვეთის არარსებობას ნიშნავს.