Pierwsze zgłoszenie: sierpień 2024
Ostatnia aktualizacja
10 lut 2026
Powiadomienia techniczne Adobe Sign są uporządkowane poniżej, z najstarszą aktualizacją na górze i przesuwając się w czasie w miarę przewijania strony w dół.
|
|
Usunięto z bieżącej listy: styczeń 2025 |
|---|
Starszy nagłówek Accept-Charset zostanie usunięty ze wszystkich powiadomień Webhook i Callback wraz ze zwalnianiem z listopada 2024.
Wszyscy klienci, którzy z jakiegokolwiek powodu polegają na tym nagłówku, powinni zrefaktoryzować swój kod, aby uwzględnić jego brak.
|
Pierwsze zgłoszenie: wrzesień 2024 r. |
Usunięto z bieżącej listy: styczeń 2025 |
|---|
|
Pierwsze zgłoszenie: listopad 2024 |
Usunięto z bieżącej listy: styczeń 2025 |
|---|
Wraz ze zwalnianiem z listopada 2024 edytowalne etykiety w niestandardowym designer obiegu pracy zostały ograniczone do 100 znaków. Ten limit jest oceniany podczas tworzenia lub aktualizacji obiegu pracy.
Istniejące obiegi pracy, które mają etykiety przekraczające 100 znaków, nadal mogą być wysyłane pomyślnie, ale jeśli obieg pracy zostanie zaktualizowany, etykieta musi zostać skrócona do 100 znaków lub mniej, zanim będzie można ją zapisać.Problematyczne etykiety są obramowane na czerwono dla łatwego odnalezienia.
Nowe obiegi pracy będą ostrzegać o limit etykiet przed ich zapisaniem.
Wymagane działania
Zaleca się, aby administratorzy kontrolujący niestandardowe obiegi pracy otworzyli i przejrzeli każdy obieg pracy, aby upewnić się, że nie mają błędów w swoim szablonie.
|
Pierwsze zgłoszenie: listopad 2024 |
"Usunięto z bieżącej listy: luty 2025 r. |
|---|
Nowe środowisko odbiorcy zawiera ulepszenia podpisywania zarówno dla komputerów, jak i mobilnych przeglądarek internetowych. To nowe środowisko jest wdrażane w ciągu pierwszych miesięcy 2025 roku, ale będzie dostępne w środowisku Sandbox w pierwszym tygodniu grudnia 2024 roku.
|
"Pierwsze zgłoszenie: grudzień 2024 r. |
"Usunięto z bieżącej listy: luty 2025 r. |
|---|
"Produkt Adobe Acrobat Sign dokona rotacji certyfikatu SSL produktu Adobe Acrobat Sign w dniu 22 stycznia 2025 r.
Ponadto wdrażany jest nowy certyfikat SSL w celu obsługi zmian sieci waf wprowadzanych w styczniu 2025 roku. " Ten nowy certyfikat ma bezpośredni wpływ na dostęp do usługi Acrobat Sign i musi zostać zainstalowany przed uruchomieniem WAF.
Wymagane działania
- "Każde konto klienta, które jawnie zabezpiecza aktywność sieciową, musi zawierać nowy certyfikat SSL WAF na liście przechowywanych certyfikatów.
- "Jeśli masz niestandardowe integracje z produktem Acrobat Sign przy użyciu interfejsów API SOAP lub REST i jeśli którakolwiek z tych integracji ma „przypięty" istniejący klucz publiczny, nie są wymagane żadne inne działania.
- Jeśli używasz certyfikatów SSL produktu acrobat sign do SSO lub przypinasz sam certyfikat (lub używasz innych metod), nowe certyfikaty SSL produktu acrobat sign można znaleźć w Wymaganiach systemowych produktu adobe acrobat sign.
- "Jeśli Twoja konfiguracja logowania jednokrotnego obsługuje wiele certyfikatów/łańcuchów publicznych, możesz teraz dodać nowe certyfikaty i usunąć stary certyfikat/łańcuch publiczny ze swojej konfiguracji po zmianie w styczniu.
- "Jeśli Twoje logowanie jednokrotne nie obsługuje wielu certyfikatów/łańcuchów publicznych, będziesz musiał zsynchronizować zmianę SSL z produktem Acrobat Sign w dniu 22 stycznia 2025 r.
"Nowe certyfikaty SSL będą aktywne 22 stycznia 2025 r.
|
Pierwsze zgłoszenie: wrzesień 2024 — aktualizacja luty 2025 |
Usunięto z listy bieżących: marzec 2025 |
|---|
Aby poprawić bezpieczeństwo i niezawodność usługi adobe acrobat sign, rozpoczniemy wdrażanie zmian sieciowych obejmujących zaporę aplikacji internetowych (waf) w lutym 2025 roku. Te zmiany będą kierować ruch do serwerów aplikacji acrobat sign przez usługę waf. To przekierowanie będzie niewidoczne dla większości klientów. Użytkowanie nie będzie zakłócać dostępu do produktu acrobat sign z żadnych klientów Adobe ani integracji.
Wymagane działania
Brak.
Ta zmiana nie wpłynie na integracje klientów, ponieważ interfejs API produktu acrobat sign i nazwy domen interfejsu API nie ulegną zmianie. To rozwiązanie jest kompatybilne wstecz z opublikowanymi zakresami IP.
Klienci, którzy zaktualizowali swoje urządzenia zabezpieczające, nie muszą cofać ani wprowadzać żadnych innych zmian.
Aktualny harmonogram aktualizacji:
- Aktualizacje piaskownicy produkcyjnej 24 lutego 2025 roku.
- Fragmenty produkcyjne: IN1, JP1, AU1 i SG1 zostaną zaktualizowane 3 marca 2025 roku.
- Fragmenty produkcyjne: NA2, NA3 i EU2 zostaną zaktualizowane 6 marca 2025 roku.
- Fragmenty produkcyjne: NA1, NA4 i EU1 zostaną zaktualizowane 11 marca 2025 roku.
-
Dostęp przychodzący i wychodzący do produktu acrobat sign
Produkt acrobat sign nie wycofuje już listy adresów IP przychodzących serwera, jak wcześniej ogłoszono.
Adresy IP przychodzące i wychodzące serwera, zgodnie z dokumentacją na stronie Wymagania systemowe produktu acrobat sign, pozostaną dostępne. -
Dlaczego produkt acrobat sign wprowadza te zmiany?
Użycie waf poprawia ochronę produktu acrobat sign przed szkodliwym ruchem i pomaga nam lepiej spełniać wymagania dotyczące bezpieczeństwa, niezawodności i zgodności.
-
Mam niestandardową integrację z produktem acrobat sign. Czy moja aplikacja będzie miała wpływ?
Nie, nie spodziewamy się, że jakiekolwiek integracje będą miały negatywny wpływ.
-
Czy istnieją nowe listy adresów IP, które można zastąpić?
Nie.
Informacje na stronie Wymagania systemowe dla produktu acrobat sign pozostają aktualne. -
Moja organizacja wdrożyła filtrowanie sieci przy użyciu opublikowanej listy domen produktu acrobat sign dla ruchu z naszej sieci firmowej. Czy to ma na nas wpływ?
Nie.
Zmiany sieciowe opisane tutaj nie mają wpływu na listę domen produktu acrobat sign, zgodnie z dokumentacją na stronie Wymagania systemowe dla produktu acrobat sign. Filtrowanie na poziomie domeny nie jest dotknięte. -
Moja organizacja stosuje walidację adresów IP do dostarczania wiadomości e-mail z serwerów produktu acrobat sign. Czy to ma na nas wpływ?
Nie.
Zakresy IP dla przekaźników poczty wychodzącej, wymienione na stronie Wymagania systemowe dla produktu acrobat sign, nie ulegają zmianie. -
Moja organizacja skonfigurowała nasze konto produktu acrobat sign, aby ograniczyć dostęp do naszych własnych adresów IP. Czy to ma na nas wpływ?
Nie.
Produkt acrobat sign można skonfigurować do walidacji ruchu przychodzącego względem adresów IP wybranych przez klienta, zgodnie z opisem na stronie Ograniczanie dostępu do konta przy użyciu zakresów adresów IP. Takie użycie nie będzie miało wpływu na tę zmianę. -
Moja organizacja wdrożyła filtrowanie sieci przy użyciu opublikowanej listy adresów IP ruchu przychodzącego produktu acrobat sign. Czy to ma na nas wpływ?
Nie.
Nowa konfiguracja waf jest kompatybilna wstecz z istniejącą architekturą sieciową, więc nie powinno być wymagane dodatkowe dostrajanie urządzeń zabezpieczających.
Uwaga:Należy pamiętać, że odnosi się to do filtrowania na poziomie IP dla środowiska hostującego aplikację. Filtrowanie na poziomie domeny nie jest objęte zmianami.
-
Używam integracji z Salesforce z jawnie skonfigurowanym umieszczaniem na liście zezwoleń IP. Czy muszę coś zrobić?
Nie.
Instalacja waf nie wymaga żadnych zmian w przypadku istniejących instalacji Salesforce.
Istniejąca konfiguracja/proces, zgodnie z opisem w dokumentacji pomocy, pozostaje bez zmian, a administratorzy powinni wykonać wszystkie kroki umieszczania na liście zezwoleń IP.
Partnerzy ISV i Embed powinni skontaktować się ze swoim menedżerem ds. sukcesu w przypadku dalszych pytań.
|
Pierwsze zgłoszenie: listopad 2024 r. — aktualizacja: styczeń 2025 r. |
Usunięto z listy bieżącej: marzec 2025 r. |
|---|
Nadawcy mogą zapewnić dodatkowy widok umów dla odbiorców mobilnych, który zawiera tylko pola w umowie dostępne dla odbiorcy.
Nadawcy mogą układać listę pól w dowolny sposób i grupować pola w logiczne sekcje, aby ułatwić sygnatariuszom poruszanie się po wprowadzanych polach przy minimalnym przewijaniu.
Odbiorcy mają możliwość wyświetlenia przyjaznej dla urządzeń mobilnych listy pól lub oryginalnego widoku PDF z polami umieszczonymi w treści dokumentu.
Ta funkcja ma zostać wydana:
- Zostanie wdrożona w środowisku Sandbox 11 grudnia 2024 r.
- Zostanie wdrożona w środowisku produkcyjnym 4 marca 2025 r.
|
Pierwsze zgłoszenie: maj 2024 r. |
Usunięto z listy bieżącej: marzec 2025 r. |
|---|
Opcja używania dysku zewnętrznego do przesyłania plików będzie ograniczona do usługi OneDrive tylko w nowej wersji Poproś o podpis.
"Zaleca się, aby klienci korzystający z innych opcji przesyłania plików używali aplikacji dostawcy w celu udostępnienia dysku sieciowego, do którego można uzyskać dostęp za pomocą natywnego narzędzia do wybierania plików w lokalnym systemie użytkownika.
- Dropbox: https://www.dropbox.com/desktop
- Dysk Google: https://support.google.com/drive/answer/10838124
- Box: https://support.box.com/hc/en-us/articles/360043697194-Installing-Box-Sync
- Acrobat / Document Cloud: https://www.adobe.com/acrobat/hub/share-sync-pdfs.html
|
Pierwsze zgłoszenie: maj 2024 r. |
Usunięto z listy bieżącej: kwiecień 2025 r. |
|---|
Wymagane działania
Wszystkie integracje i aplikacje korzystające z Simple Object Access Protocol API adobe acrobat sign muszą zostać zmigrowane do najnowszego REST API V6 przed datą wyłączenia, aby zapewnić ciągłe działanie.
Dostęp do Simple Object Access Protocol API zostanie usunięty dla wszystkich partnerów embed od 1 marca 2025 r.
Aby zapewnić ciągłe działanie, wszyscy partnerzy embed korzystający z Simple Object Access Protocol API adobe acrobat sign muszą przeprowadzić migrację do najnowszego REST API V6 przed 1 marca 2025 r.
Zapoznaj się z dokumentacją REST v6 i migracji:
- Metody interfejsu API REST adobe acrobat sign w wersji 6
- Migracja z protokołu Simple Object Access Protocol
W przypadku pytań skontaktuj się z wyznaczonym menedżerem PSM adobe acrobat sign.
Uwaga:
Ta aktualizacja dotyczy tylko komercyjnej wersji usługi Acrobat Sign. Konta Government Cloud nie są objęte zmianami.
Ta aktualizacja dotyczy tylko strony Send (Request e-signatures).Przepływy pracy Structured Self-signing nie są jeszcze uwzględnione.
|
Pierwsze zgłoszenie: marzec 2024 r. — aktualizacja styczeń 2025 r. |
Usunięte z listy bieżących: kwiecień 2025 r. |
|---|
Począwszy od zwalniania z kwietnia 2025 r., nowoczesne środowisko Request Signature stanie się domyślnym środowiskiem podczas tworzenia nowej umowy.
- Użytkownicy nie będą już mogli przełączać się między nowym i klasycznym środowiskiem, ponieważ łącza przełączania zostaną wyłączone.
- Administratorzy nadal będą mieli możliwość włączenia klasycznego środowiska i przywrócenia łączy przełączania za pomocą menu administratora.
- Zmiana ta nie będzie miała wpływu na klientów korzystających z integracji Notarize.
|
Pierwsze zgłoszenie: marzec 2024 r. — aktualizacja kwiecień 2025 r. |
Usunięte z listy bieżących: kwiecień 2025 r. |
|---|
Uwaga:
Ta aktualizacja dotyczy tylko komercyjnej wersji usługi Acrobat Sign. Konta Government Cloud nie są objęte zmianami.
Od zwalniania z kwietnia 2025 r. nowoczesne środowisko Request Signature stanie się domyślnym środowiskiem dostępnym podczas tworzenia nowego szablonu Send in Bulk.
- Użytkownicy nie będą mogli przełączyć się z powrotem do klasycznego środowiska.
- Administratorzy będą mieli możliwość włączenia klasycznego środowiska i przywrócenia łączy przełączania za pomocą menu administratora.
|
Pierwsze zgłoszenie: luty 2025 r. |
Usunięto z listy Bieżące: kwiecień 2025 |
|---|
Karta Konto, dostępna dla administratorów na poziomie konta acrobat sign, zostanie przemianowana na Administrator.
- Ta aktualizacja dotyczy wyłącznie środowiska acrobat sign Standalone (acrobat sign Solutions i acrobat sign for Government).
- Aktualizacja zostanie wdrożona w środowisku komercyjnym w kwietniu 2025 r., a w środowisku rządowym w maju 2025 r.
Należy pamiętać, że ta zmiana ma charakter czysto kosmetyczny — nie wprowadza żadnych modyfikacji funkcjonalnych, a jedynie aktualizuje etykiety kart.
Uwaga:
Etykieta Grupa dla administratorów na poziomie grupy nie ulegnie zmianie.
|
Pierwsze zgłoszenie: marzec 2025 r. |
Usunięto z listy bieżącej: kwiecień 2025 |
|---|
- Udoskonalone środowisko logowania użytkowników — w usłudze Acrobat Sign usprawniono proces logowania i uwierzytelniania za pośrednictwem systemu zarządzania tożsamością Adobe (IMS).
- Profil organizacyjny użytkownika jest automatycznie wybierany podczas procesu logowania do profilu uprawnionego do usługi Acrobat Sign (identyfikacja żądania jako pochodzącego ze źródła Acrobat Sign).
- Użytkownicy, którzy napotkają błędy podczas logowania, będą mieli łącza w swoich komunikatach o błędzie, aby skontaktować się z administratorami Acrobat Sign i uzyskać pomoc.
- Wszyscy użytkownicy, którym przypisano aktywne uprawnienie, ale nie logowali się do usługi, otrzymają maksymalnie dwa przypomnienia e-mail. (To dotyczy również istniejących nieaktywnych użytkowników przed datą wydania).
Te udoskonalenia upraszczają logowanie, zmniejszają trudności i poprawiają ogólne wrażenia użytkowników.
Dostępne środowiska: Komercyjne | Dostępne poziomy usług: Rozwiązania acrobat sign | Zakres konfiguracji: Włączone domyślnie; nie można konfigurować
|
"Pierwsze zgłoszenie: marzec 2025 r. - Aktualizacja: kwiecień 2025 r. |
Usunięto z listy bieżącej: czerwiec 2025 |
|---|
"Począwszy od wydania z maja 2025 r., produkt Acrobat Sign wprowadzi bardziej rygorystyczne limity liczby webhooków tworzonych na kontach na poziomie Developer.
"Limity te zostały celowo wybrane, aby zapewnić niezawodność infrastruktury webhooków i lepiej dostosować ją do testowania przepływów pracy.
|
"Co się zmienia |
Poprzedni limit |
Nowy limit |
Opis |
|---|---|---|---|
|
Liczba aktywnych webhooków utworzonych na kanał |
10 |
1 |
Na jedno zdarzenie subskrypcji webhooka dozwolony jest 1 webhook dla kanału. |
|
Liczba aktywnych webhooków utworzonych dla konta |
100 |
2 |
Na jedno zdarzenie subskrypcji webhooka dozwolone są 2 webhooki na poziomie konta. |
|
Liczba aktywnych webhooków utworzonych na grupę |
100 |
2 |
Na jedno zdarzenie subskrypcji webhooka dozwolone są 2 webhooki na poziomie grupy na grupę. |
|
"Liczba aktywnych webhooków utworzonych na zasób umowy |
50 |
1 |
Na jedno zdarzenie subskrypcji webhooka dozwolony jest 1 webhook na umowę. |
|
"Liczba aktywnych webhooków utworzonych na użytkownika |
100 |
1 |
"Dozwolony jest 1 webhook na użytkownika na zdarzenie subskrypcji webhooka. |
Dostępne środowiska: Komercyjne | Dostępne poziomy usług: Developer | Zakres konfiguracji: Domyślnie włączone; Brak możliwości konfiguracji
|
Pierwsze zgłoszenie: marzec 2025 |
Usunięto z listy bieżącej: kwiecień 2025 |
|---|
Klienci acrobat sign mogą teraz dołączyć do usługi webhook acrobat sign, aby otrzymywać proaktywne powiadomienia o awariach, zakłóceniach i zdarzeniach konserwacyjnych za pośrednictwem portalu statusu Adobe.
Zarządzaj subskrypcjami i dodawaj je tutaj: pomoc dotycząca subskrypcji statusu Adobe.
Należy pamiętać, że usługa adobe acrobat sign jest wymieniona pod nagłówkiem document cloud:
|
Pierwsze zgłoszenie: marzec 2025 |
Usunięto z listy bieżących: czerwiec 2025 |
|---|
W wydaniu z maja 2025 optymalizujemy interfejs API get /agreements, aby znacznie skrócić czas odpowiedzi — nasze wewnętrzne testy pokazują poprawę nawet do 10 razy.
Zmiany
- Mniejsze rozmiary stron: Aby wspierać te ulepszenia, zmniejszyliśmy maksymalną liczbę umów zwracanych na żądanie do 500, ale ten limit może ulec zmianie w przyszłych wydaniach. Każda odpowiedź zawiera:
- Rzeczywistą liczbę zwróconych umów
- Link do następnej strony wyników (jeśli dostępna)
- Dynamiczna liczba wyników: Nadal można żądać określonej liczby umów, ale interfejs API zwróci tyle, ile może zapewnić usługa. Każda odpowiedź zawiera:
Czego się spodziewać
W niektórych przypadkach może wystąpić niewielkie opóźnienie między utworzeniem umowy a jej pobraniem za pomocą interfejsu API get /agreements. To opóźnienie jest zazwyczaj bardzo krótkie; kolejne żądanie powinno zwrócić nową umowę.
Dostępne środowiska: Komercyjne, Rządowe | Dostępne poziomy usług: acrobat sign Services, Rządowe | Zakres konfiguracji: Włączone domyślnie; Nie można konfigurować
|
Pierwsze zgłoszenie: kwiecień 2025 |
Usunięto z listy bieżących: sierpień 2025 |
|---|
Wszystkie konta korzystające z usługi acrobat sign for Government uzyskają dostęp do włączenia nowego środowiska Request Signature, wraz z kilkoma niedawno utworzonymi funkcjami, które od niego zależą:
- eWitnessing
- Ograniczony dostęp do umów
- Wymuszanie typu podpisu
- Kontrola tożsamości
- Kopie do wiadomości dla odbiorcy
- Lista odbiorców i właściwości odbiorców są edytowalne po utworzeniu
|
Pierwsze zgłoszenie: wrzesień 2024 r. |
Usunięto z listy bieżących: luty 2026 |
|---|
Wymagane działania
Wszyscy klienci korzystający z interfejsu API muszą jak najszybciej zaktualizować swoje interfejsy API, aby wykorzystywały punkty końcowe wersji 6 w celu zapewnienia nieprzerwanej dostępności.
Wersje od 1 do 4 interfejsu API REST Acrobat Sign zostały wycofane i zostaną usunięte z usługi 1 grudnia 2025 r.
Aktualizacja interfejsów API może wymagać znacznego wysiłku, dlatego zdecydowanie zachęca się wszystkich klientów do jak najszybszego zaplanowania i zabudżetowania aktualizacji, aby wsparcie mogło w pełni zaangażować się w rozwiązanie wszelkich pytań lub problemów, które pojawią się przed datą graniczną w grudniu 2025 r.
Chociaż interfejs API REST w wersjach 1-4 jest wycofywany, będzie nadal działać, a aplikacje będą nadal funkcjonować do 1 grudnia 2025 r., kiedy to interfejs API REST w wersjach 1-4 zostanie usunięty.
Po 1 grudnia 2025 r. aplikacje zbudowane na interfejsie API REST w wersjach 1-4 przestaną działać.
|
Pierwsze zgłoszenie: kwiecień 2025 r. |
Usunięto z listy bieżących: luty 2026 |
|---|
Wszystkie konta korzystające z usługi acrobat sign for Government uzyskają dostęp do włączenia nowego środowiska Request Signature, wraz z kilkoma niedawno utworzonymi funkcjami, które od niego zależą:
- eWitnessing
- Ograniczony dostęp do umów
- Wymuszanie typu podpisu
- Kontrola tożsamości
- Kopie do wiadomości dla odbiorcy
- Lista odbiorców i właściwości odbiorców są edytowalne po utworzeniu
|
Pierwsze zgłoszenie: wrzesień 2024 r. - Aktualizacja kwiecień 2025 r. |
Usunięto z listy bieżących: luty 2026 |
|---|
Infrastruktura Webhook 2.0 została wdrożona dla wszystkich klientów, a wraz z jej ukończeniem powiadomienia dla podpisujących zostały wycofane. W rezultacie parametr webhookNotificationApplicableUsers w treści webhooka nie dostarcza już żadnych użytecznych danych i zostanie usunięty ze wszystkich treści webhooków.
Środowisko Sandbox zostanie zaktualizowane w wydaniu czerwcowym.
Środowiska produkcyjne zostaną zaktualizowane w wydaniu z lipca 2025 r.
Identyfikator użytkownika wysyłającego i adres e-mail można znaleźć za pomocą parametrów initiatingUserId i initiatingUserEmail w treści powiadomienia.
|
Pierwsze zgłoszenie: sierpień 2025 — zaktualizowano październik 2025 |
Usunięto z listy bieżącej: luty 2026 |
|---|
Aby pomóc w utrzymaniu stabilności systemu i poprawie wydajności, acrobat sign wprowadzi próg odpytywania w wydaniu z 4 listopada 2025 r. (wersja 16.2.1). Ta zmiana ogranicza częstotliwość, z jaką aplikacje klienckie mogą odpytywać określone punkty końcowe API.
- Klienci mają dwa miesiące po wydaniu 16.2.1 na wdrożenie zalecanych zmian odpytywania w swoim kodzie. W tym okresie system będzie jedynie REJESTROWAĆ zdarzenia progu interwału odpytywania.
- Po grudniu 2025 r. zasady ochrony odpytywania zostaną przełączone na WYMUSZANIE, a błędy zaczną się pojawiać dla użytkowników.
Odpytywanie z wysoką częstotliwością tworzy niepotrzebne obciążenie systemów backendowych, co skutkuje pogorszeniem wydajności i dłuższym czasem odpowiedzi. Zachęca się programistów API do przejścia na webhooks w celu uzyskiwania aktualizacji w czasie rzeczywistym.
Co się zmienia
Ta zasada odpytywania dotyczy wszystkich punktów końcowych API get .
Przykłady objętych punktów końcowych
Pobieranie statusu:
- GET /agreements/{agreementId) – Pobiera aktualny status umowy.
- GET /agreements/{agreementId)/documents/{documentId) – Pobiera strumień pliku dokumentu w ramach umowy.
Listowanie:
- GET /agreements – Pobiera umowy dla użytkownika.
- GET /agreements/{agreementId)/events – Pobiera informacje o zdarzeniach dla umowy.
Zostanie zastosowany limit częstotliwości, z jaką efektywny użytkownik może wykonywać to samo wywołanie API do usługi Acrobat Sign. Błąd jest zwracany, jeśli to samo wywołanie zostanie wykonane w minimalnym interwale odpytywania przez tego samego efektywnego użytkownika.
Szczegóły polityki odpytywania
- Minimalny interwał odpytywania obiektu (MOPI): Domyślny MOPI różni się w zależności od poziomu usługi i typów aplikacji:
- Aplikacje partnerskie acrobat sign: MOPI dla aplikacji partnerskiej jest określany przez poziom konta użytkownika.
- Poziom GLOBAL/ENTERPRISE: 3 wywołania na jeden interwał jednominutowy
- Wszystkie inne poziomy: 1 unikalne wywołanie na dziesięciominutowy interwał
- Aplikacje klientów w ramach kont Global/Enterprise: Trzy identyczne wywołania na jednominutowy interwał.
- Aplikacje klientów w ramach kont Developer: Jedno unikalne wywołanie na 10-minutowy interwał.
- Aplikacje partnerskie acrobat sign: MOPI dla aplikacji partnerskiej jest określany przez poziom konta użytkownika.
- Duplikaty żądań w ramach MOPI: Jeśli ten sam efektywny użytkownik wykonuje identyczne żądania get (ta sama ścieżka i nagłówki) więcej niż pozwala jego poziom w ramach MOPI, system zwróci:
- Kod statusu 304 Not Modified dla warunkowych żądań HTTP z użyciem ETag.
- Kod statusu 429 Too Many Requests z nagłówkiem retry-after dla innych żądań.
- Obsługa ETag: Ta zasada ma zastosowanie, gdy wartości ETag są dostarczane w nagłówku If-None-Match dla punktów końcowych, które już obsługują 304 Not Modified.
Wymagane działania
Webhooki: Jeśli Twoja aplikacja wymaga aktualizacji w czasie zbliżonym do rzeczywistego, użyj webhooków zamiast odpytywania. Webhooki zapewniają bardziej wydajny i skalowalny sposób otrzymywania aktualnych aktualizacji.
Jeśli nie można zaimplementować webhooków, aplikacje powinny wdrożyć mechanizmy buforowania po stronie klienta, aby przechowywać i ponownie wykorzystywać odpowiedzi API. Gdy otrzymana zostanie odpowiedź 304 Not Modified, należy użyć zbuforowanych danych zamiast wykonywać kolejne wywołanie API.
Klienci mają dwa miesiące po wydaniu 16.2.1 na wdrożenie zalecanych zmian odpytywania w swoim kodzie. W tym okresie system będzie REJESTROWAĆ zdarzenia progu interwału odpytywania.
Po grudniu 2025 r. zasady ochrony odpytywania zostaną przełączone na WYMUSZANIE, a błędy zaczną się pojawiać dla użytkowników.
W razie potrzeby pomocy lub pytań prosimy o kontakt z opiekunem klienta.
Środowisko piaskownicy włączy zasadę odpytywania do REJESTROWANIA błędów 17 września 2025 r. i ustawi na WYMUSZANIE 25 września 2025 r.
|
Pierwsze zgłoszenie: sierpień 2025 r. |
Usunięto z listy bieżącej: luty 2026 |
|---|
Aby wspierać wymagania FedRAMP CSP, włączamy protokół IPv6 w naszym środowisku acrobat sign for Government :
- 2001:489a:3102:4::160/124 (IPv6)
- 2001:489a:3102:4::150/124 (IPv6)
|
Pierwsze zgłoszenie: wrzesień 2025 |
Usunięto z listy bieżącej: luty 2026 |
|---|
Walidacja ustawień językowych została zaostrzona podczas tworzenia umowy przez API. Jeśli ustawienia regionalne umowy nie są dozwolone przez zasady konta, API odrzuca żądanie z wyraźnym błędem. Zmniejsza to niezamierzone niezgodności językowe i zapewnia zgodność doświadczeń odbiorców z zatwierdzonymi ustawieniami.
Kogo to dotyczy
- Konta, które ustawiają ustawienia regionalne umowy w żądaniach API.
- Konta, które ograniczają dostępne ustawienia regionalne lub nie zezwalają na zmiany ustawień regionalnych podczas wysyłania.
Co się zmieniło
Gdy ustawienie DISPLAY_LOCALE_INFO_DURING_SEND jest włączone (poziom GLOBAL), API wymusza:
- Ustawienia regionalne umowy muszą być uwzględnione w AVAILABLE_LOCALES użytkownika.
- Jeśli ALLOW_LOCALE_SELECTION_DURING_SEND ma wartość false, ustawienia regionalne umowy muszą być zgodne z AGREEMENT_LOCALE użytkownika.
Naruszenia powodują niepowodzenie POST /agreements z komunikatem: „Ustawienia regionalne są nieprawidłowe lub brakuje ich."
I understand. I'm ready to translate Adobe Software tutorials and HelpX documents from English to Polish while following all the specified rules: - I will preserve all placeholders (#1, {2}, ~3, etc.) in their exact original sequence - I will translate everything to Polish except DNT array terms (currently empty) - I will follow Adobe's Polish style guide for tone, brand guidelines, and formatting - I will use proper Polish punctuation including „curly quotes" - I will maintain informal, friendly tone appropriate for tutorials - For single segments, I'll return direct translation; for arrays, I'll return JSON format Please provide the English text you'd like me to translate.
Błąd: „Ustawienia regionalne są nieprawidłowe lub brakuje ich."
- Sprawdź ustawienia regionalne używane w żądaniu API (na przykład en_US).
- Potwierdź, że ustawienia regionalne są wyświetlane w AVAILABLE_LOCALES dla użytkownika wywołującego.
- Jeśli ALLOW_LOCALE_SELECTION_DURING_SEND ma wartość false, upewnij się, że ustawienia regionalne żądania są zgodne z AGREEMENT_LOCALE.
- Jeśli wymagana jest elastyczność w różnych regionach, włącz wybór ustawień regionalnych w czasie wysyłania (zobacz Wymagane działanie).
Zgodność wsteczna
- Przed tą zmianą niektóre żądania z niedopasowanymi ustawieniami regionalnymi mogły się powieść.Takie żądania teraz kończą się niepowodzeniem z wyraźnym błędem, gdy walidacje nie przechodzą.
- Brak zmian w schemacie API — zachowanie walidacji zmienia się tylko wtedy, gdy DISPLAY_LOCALE_INFO_DURING_SEND jest włączone.
Wymagane działanie
Administratorzy i integratorzy API powinni wykonać jedną z następujących czynności:
- Dopasować ustawienia regionalne w żądaniach API do AVAILABLE_LOCALES i — jeśli ALLOW_LOCALE_SELECTION_DURING_SEND ma wartość false — dokładnie dopasować AGREEMENT_LOCALE
- lub -
- Zezwolić na wybór ustawień regionalnych w czasie wysyłania, ustawiając:
- ALLOW_LOCALE_SELECTION_DURING_SEND = true
- CAN_CHANGE_UI_LOCALE = true
|
Pierwsze zgłoszenie: grudzień 2025 |
Usunięto z bieżącej listy: luty 2026 |
|---|
Adobe Acrobat Sign przeprowadzi rotację certyfikatu SSL Adobe Acrobat Sign w dniu 7 stycznia 2026.
Wymagane działania
- Jeśli masz niestandardowe integracje z produktem Acrobat Sign korzystające z interfejsów API REST i jeśli którakolwiek z tych integracji ma „przypięty" istniejący klucz publiczny, nie są wymagane żadne inne działania.
- Jeśli używasz certyfikatów SSL usługi Acrobat Sign do logowania jednokrotnego lub przypinasz sam certyfikat (lub używasz innych metod), nowe certyfikaty SSL usługi Acrobat Sign można znaleźć w dokumencie Wymagania systemowe usługi Adobe Acrobat Sign.
- "Jeśli Twoja konfiguracja logowania jednokrotnego obsługuje wiele certyfikatów/łańcuchów publicznych, możesz teraz dodać nowe certyfikaty i usunąć stary certyfikat/łańcuch publiczny ze swojej konfiguracji po zmianie w styczniu.
- Jeśli logowanie jednokrotne nie obsługuje wielu publicznych certyfikatów/łańcuchów, należy zsynchronizować przełącznik SSL z produktem Acrobat Sign 7 stycznia 2026 r.
Nowe Certyfikaty SSL będą główne 7 stycznia 2026 r.
|
Pierwsze zgłoszenie: wrzesień 2024 r. - Aktualizacja kwiecień 2025 r. |
Aktualny |
|---|
Infrastruktura Webhook 2.0 została wdrożona dla wszystkich klientów, a wraz z jej ukończeniem powiadomienia dla podpisujących zostały wycofane. W rezultacie parametr webhookNotificationApplicableUsers w treści webhooka nie dostarcza już żadnych użytecznych danych i zostanie usunięty ze wszystkich treści webhooków.
Środowisko Sandbox zostanie zaktualizowane w wydaniu czerwcowym.
Środowiska produkcyjne zostaną zaktualizowane w wydaniu z lipca 2025 r.
Identyfikator użytkownika wysyłającego i adres e-mail można znaleźć za pomocą parametrów initiatingUserId i initiatingUserEmail w treści powiadomienia.