Zuerst veröffentlicht: August 2024
Zuletzt aktualisiert am
3. Juni 2026
Die Adobe Sign Technischen Benachrichtigungen sind unten sortiert, wobei das älteste Update ganz oben steht und die Zeit nach vorne rollt, während du die Seite nach unten scrollst.
|
|
Aus der aktuellen Liste entfernt: Januar 2025 |
|---|
Der veraltete Header „Accept-Charset“ wird in der Version vom November 2024 aus allen Webhook- und Rückrufbenachrichtigungen entfernt.
Alle Kundinnen und Kunden, die diesen Header nutzen, sollten ihren Code umschreiben, damit er in Abwesenheit des Headers weiter funktioniert.
|
Zuerst veröffentlicht: September 2024 |
Aus der aktuellen Liste entfernt: Januar 2025 |
|---|
|
Zuerst veröffentlicht: November 2024 |
Aus der aktuellen Liste entfernt: Januar 2025 |
|---|
Mit der Version von November 2024 wurden die bearbeitbaren Bezeichnungen im Custom Workflow Designer auf 100 Zeichen begrenzt. Diese Begrenzung wird geprüft, wenn der Workflow erstellt oder aktualisiert wird.
Vorhandene Workflows mit Bezeichnungen von mehr als 100 Zeichen können weiterhin erfolgreich gesendet werden, doch wenn der Workflow aktualisiert wird, muss die Bezeichnung auf 100 Zeichen oder weniger reduziert werden, bevor er gespeichert werden kann. Beanstandete Bezeichnungen sind zur besseren Auffindbarkeit rot umrandet.
Bei neuen Workflows wird vor dem Speichern eine Warnung angezeigt, wenn das Bezeichnungslimit überschritten wird.
Handlungsbedarf
Administrierende, die selbstdefinierte Workflows verwalten, sollten jeden Workflow öffnen und überprüfen, um zu gewährleisten, dass dessen Vorlage keine Fehler enthält.
|
Zuerst veröffentlicht: November 2024 |
Aus der aktuellen Liste entfernt: Februar 2025 |
|---|
Das neue Empfängererlebnis enthält Verbesserungen beim Signieren für Desktop- und mobile Webbrowser.Dieses neue Erlebnis wird in den ersten Monaten des Jahres 2025 eingeführt, wird aber in der ersten Dezemberwoche 2024 in der Sandbox-Umgebung verfügbar sein.
|
Zuerst veröffentlicht: Dezember 2024 |
Aus der aktuellen Liste entfernt: Februar 2025 |
|---|
Adobe Acrobat Sign tauscht das Adobe Acrobat Sign SSL-Zertifikat am 22. Januar 2025 aus.
Außerdem wird ein neues SSL-Zertifikat bereitgestellt, um die WAF-Netzwerkänderungen zu unterstützen, die im Januar 2025 vorgenommen werden. Dieses neue Zertifikat wirkt sich direkt auf den Zugriff auf den Acrobat Sign-Dienst aus und muss installiert werden, bevor die WAF online geschaltet wird.
Handlungsbedarf
- Jedes Kundenkonto, das Netzwerkaktivitäten explizit sichert, muss das neue WAF-SSL-Zertifikat in die Liste der gespeicherten Zertifikate aufnehmen.
- Wenn du über benutzerdefinierte Integrationen mit Acrobat Sign verfügst, die entweder die SOAP- oder die REST-API verwenden, und für diese Integrationen der vorhandene öffentliche Schlüssel „angeheftet“ ist, musst du darüber hinaus nichts tun.
- Wenn du die SSL-Zertifikate von Acrobat Sign für SSO verwendest oder das Zertifikat selbst pinnst (oder andere Methoden verwendest), findest du die neuen Acrobat Sign SSL-Zertifikate in den Acrobat Sign Systemanforderungen.
- Wenn deine SSO-Konfiguration mehrere öffentliche Zertifikate/Chains unterstützt, kannst du die neuen Zertifikate jetzt hinzufügen und das alte öffentliche Zertifikat/die alte Chain nach der Januar-Änderung aus deiner Konfiguration entfernen.
- Wenn dein SSO nicht mehrere öffentliche Zertifikate/Chains unterstützt, musst du deine SSL-Änderung am 22. Januar 2025 mit Acrobat Sign synchronisieren.
Die neuen SSL-Zertifikate sind ab dem 22. Januar 2025 aktiv.
|
Zuerst veröffentlicht: September 2024 – Aktualisiert: Februar 2025 |
Von der aktuellen Liste entfernt: März 2025 |
|---|
Um die Sicherheit und Stabilität des Adobe Acrobat Sign-Dienstes zu verbessern, werden wir im Februar 2025 Netzwerkänderungen einführen, um eine Web Application Firewall (WAF) einzubinden. Durch diese Änderungen wird der Traffic über den WAF-Dienst an die Acrobat Sign-Anwendungsserver weitergeleitet. Dieses Routing ist für die meisten Kundinnen und Kunden nicht sichtbar. Die Nutzung hat keinen Einfluss auf den Zugriff auf Acrobat Sign von Adobe-Clients oder -Integrationen.
Handlungsbedarf
Keiner.
Diese Änderung wirkt sich nicht auf Kundenintegrationen aus, da sich die Acrobat Sign-API- und API-Domänennamen nicht ändern. Diese Lösung ist mit den veröffentlichten IP-Bereichen abwärtskompatibel.
Kundinnen und Kunden, die ihre Sicherheitseinrichtungen aktualisiert haben, müssen dies nicht rückgängig machen und auch keine anderen Änderungen vornehmen.
Der aktuelle Aktualisierungszeitplan lautet:
- Produktions-Sandbox wird am 24. Februar 2025 aktualisiert.
- Produktions-Shards: IN1, JP1, AU1 und SG1 werden am 3. März 2025 aktualisiert.
- Produktions-Shards: NA2, NA3 und EU2 werden am 6. März 2025 aktualisiert.
- Produktions-Shards: NA1, NA4 und EU1 werden am 11. März 2025 aktualisiert.
Eingehender und ausgehender Zugriff auf Acrobat Sign
Wie zuvor angekündigt, wird Acrobat Sign die Liste eingehender Server-IP-Adressen nicht weiterhin aus dem Dienst nehmen.
Die eingehenden und ausgehenden Server-IP-Adressen können weiterhin, wie auf der Seite Systemanforderungen für Acrobat Sign dokumentiert, genutzt werden.
Warum nimmt Acrobat Sign diese Änderungen vor?
Die Verwendung einer WAF verbessert den Acrobat Sign-Schutz vor schädlichem Traffic und hilft uns, besser mit Anforderungen an Sicherheit, Stabilität und Compliance umzugehen.
Ich habe eine benutzerdefinierte Integration in Acrobat Sign. Wird meine Anwendung betroffen sein?
Nein, wir erwarten keine negativen Auswirkungen auf Integrationen.
Gibt es neue IP-Adressenlisten, die eingesetzt werden können?
Nr.
Die Informationen auf der Seite Systemanforderungen für Acrobat Sign bleiben korrekt.
In meinem Unternehmen wurde eine Netzwerkfilterung mithilfe der veröffentlichten Domänenliste von Acrobat Sign für den Traffic aus unserem Unternehmensnetzwerk implementiert. Sind wir betroffen?
Nr.
Die hier beschriebenen Netzwerkänderungen betreffen nicht die Domain-Liste von Acrobat Sign, wie sie auf der Seite Systemanforderungen für Acrobat Sign dokumentiert ist.Die Filterung auf Domänenebene ist nicht betroffen.
Mein Unternehmen verwendet die IP-Adressenvalidierung für die E-Mail-Zustellung von Acrobat Sign-Servern. Sind wir betroffen?
Nr.
Die IP-Bereiche für ausgehende E-Mail-Relays, wie sie auf der Seite Systemanforderungen für Acrobat Sign aufgelistet sind, ändern sich nicht.
In meinem Unternehmen wurde unser Acrobat Sign-Konto so konfiguriert, dass der Zugriff auf unsere eigenen IP-Adressen eingeschränkt ist. Sind wir betroffen?
Nr.
Acrobat Sign kann so konfiguriert werden, dass eingehender Traffic gegen vom Kunden gewählte IP-Adressen validiert wird, wie auf der Seite Zugriff auf dein Konto mithilfe von IP-Adressbereichen einschränken beschrieben.Diese Änderung wirkt sich nicht auf eine derartige Nutzung aus.
In meinem Unternehmen wurde die Netzwerkfilterung mithilfe der veröffentlichten Liste der eingehenden IP-Adressen von Acrobat Sign implementiert. Sind wir betroffen?
Nein.
Die neue WAF-Konfiguration ist abwärtskompatibel mit der vorhandenen Netzwerkarchitektur, weshalb keine zusätzliche Abstimmung deiner Sicherheitseinrichtungen erforderlich ist.
Anmerkung
Beachte, dass sich dies auf die Filterung auf IP-Ebene für die Umgebung bezieht, die deine Anwendung hostet. Die Filterung auf Domänenebene ist nicht betroffen.
Ich verwende die Salesforce-Integration mit explizit konfigurierter IP-Zulassungsliste. Muss ich etwas tun?
Nein.
Die WAF-Installation erfordert derzeit keine Änderungen für vorhandene Salesforce-Installationen.
Die in der Hilfedokumentation beschriebene Konfiguration bzw. der dort beschriebene Prozess bleibt gleich und Admins sollten allen Schritten zur Zulassung über IP-Zulassungslisten folgen.
Für weitere Fragen sollten ISV- und Embed-Partnerinnen und -Partner sich an ihre Success Managerinnen und Manager wenden.
|
Zuerst veröffentlicht: November 2024 – Aktualisiert: Januar 2025 |
Von der aktuellen Liste entfernt: März 2025 |
|---|
Die sendende Partei kann eine zusätzliche Ansicht von Vereinbarungen für mobile Empfangende bereitstellen, bei der nur die Felder in der Vereinbarung angezeigt werden, die für die Empfangspartei zur Verfügung stehen.
Die sendende Partei kann die Feldliste nach Belieben anordnen und Gruppenfelder in logische Abschnitte gruppieren, um Unterzeichnenden dabei zu helfen, die Feldeingaben mit minimalem Scrollen vorzunehmen.
Empfangende haben die Möglichkeit, die mobilgerätefreundliche Felderliste oder die ursprüngliche PDF-Ansicht mit den Feldern innerhalb des Dokumentinhalts anzuzeigen.
Diese Funktion ist für die Veröffentlichung geplant:
- Wird am 11. Dezember 2024 in der Sandbox-Umgebung bereitgestellt
- Wird am Mittwoch, 4. März 2025 in der Produktionsumgebung bereitgestellt
|
Zuerst veröffentlicht: Mai 2024 |
Von der aktuellen Liste entfernt: März 2025 |
|---|
Die Option zum Verwenden eines externen Laufwerks zum Hochladen von Dateien wird in der neuen Umgebung für Signatur anfordern auf OneDrive eingeschränkt.
Es wird empfohlen, dass Kundinnen und Kunden, die andere Optionen zum Hochladen von Dateien verwenden, die spezifischen Anbieteranwendung verwenden, um ein Netzwerklaufwerk bereitzustellen, auf das das native Dateiauswahlprogramm des lokalen Systems der Benutzenden zugreifen kann.
- Dropbox: https://www.dropbox.com/desktop
- Google Drive: 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
|
Zuerst veröffentlicht: Mai 2024 |
Von der aktuellen Liste entfernt: April 2025 |
|---|
Handlungsbedarf
Alle Integrationen und Anwendungen, die die Adobe Acrobat Sign SOAP-API verwenden, müssen vor dem Deaktivierungsdatum auf die neueste REST-API V6 migriert werden, damit sie weiterhin funktionieren.
Der Zugriff auf die SOAP-API für alle eingebetteten Partnerinnen und Partner wird am 1. März 2025 entfernt.
Alle eingebetteten Partnerinnen und Partner, die die Adobe Acrobat Sign SOAP-API verwenden, müssen vor dem 1. März 2025 auf die neueste REST-API V6 migriert werden, um Funktionsunterbrechungen vorzubeugen.
Hier findest du die Dokumentation zu REST v6 und zur Migration zur Referenz:
- Adobe Acrobat Sign-REST-API Version 6 – Methoden
- Migration von SOAP
Wende dich bei Fragen an deine bzw. deinen zuständigen Adobe Acrobat Sign-PSM.
Anmerkung
Diese Aktualisierung gilt nur für die kommerzielle Version des Acrobat Sign-Dienstes. Government Cloud-Konten sind nicht betroffen.
Diese Aktualisierung gilt nur für die Seite Senden (E-Signaturen anfordern).Strukturierte Selbstsignierung-Workflows sind noch nicht enthalten.
|
Zuerst veröffentlicht: März 2024 – Aktualisiert: Januar 2025 |
Von der aktuellen Liste entfernt: April 2025 |
|---|
Ab der Version vom April 2025 wird die moderne Umgebung „Signatur anfordern“ zum Standarderlebnis für das Erstellen einer neuen Vereinbarung.
- Benutzende können nicht mehr zwischen der neuen und der klassischen Umgebung wechseln, da die Links zum Umschalten deaktiviert werden.
- Admins haben weiterhin die Möglichkeit, über das Admin-Menü das klassische Erlebnis zu aktivieren und die Links zum Umschalten wiederherzustellen.
- Kundinnen und Kunden, die die Notarize-Integration verwenden, werden von dieser Änderung nicht betroffen sein.
|
Erstmals gemeldet: März 2024 - Aktualisiert April 2025 |
Aus der aktuellen Liste entfernt: April 2025 |
|---|
Anmerkung
Diese Aktualisierung gilt nur für die kommerzielle Version des Acrobat Sign-Dienstes. Government Cloud-Konten sind nicht betroffen.
Ab der April 2025-Version wird die moderne Request Signature-Umgebung zur Standard-Erfahrung, die beim Erstellen einer neuen Send in Bulk-Vorlage verfügbar ist.
- Benutzer können nicht mehr zur klassischen Umgebung zurückwechseln.
- Administratoren haben die Möglichkeit, die klassische Erfahrung zu aktivieren und Wechsel-Links über das Administrator-Menü wiederherzustellen.
|
Zuerst veröffentlicht: Februar 2025 |
Aus der aktuellen Liste entfernt: April 2025 |
|---|
Die Registerkarte Konto, die für Acrobat Sign-Kontoadmins verfügbar ist, wird in Admin umbenannt.
- Diese Aktualisierung gilt ausschließlich für die Standalone-Umgebung von Acrobat Sign (Acrobat Sign Solutions und Acrobat Sign für Behörden).
- Für die kommerzielle Umgebung wird die Aktualisierung im April 2025 und für die Behörden-Umgebung im Mai 2025 durchgeführt.
Diese Aktualisierung ist rein kosmetischer Natur. Sie umfasst keine funktionalen Änderungen, nur Aktualisierungen der Registerkartenbeschriftungen.
Anmerkung
Das Label Gruppe für Admins auf Gruppenebene ändert sich nicht.
|
Zuerst veröffentlicht: März 2025 |
Aus aktueller Liste entfernt: April 2025 |
|---|
- Verbessertes Benutzeranmeldungserlebnis: Acrobat Sign hat den Anmelde- und Authentifizierungsprozess über das Adobe Identity Management System (IMS) optimiert.
- Wenn sich Benutzende anmelden, die eine Berechtigung für den Acrobat Sign-Dienst haben, wird für diese Personen automatisch das unternehmensspezifische Profil ausgewählt (die Anfrage wird dabei als aus einer Acrobat Sign-Quelle stammend identifiziert).
- Benutzende, die beim Anmelden auf Fehler stoßen, erhalten in ihren Fehlermeldungen Links, mit denen sie sich an ihre Acrobat Sign-Administrator*innen wenden können, um Hilfe zu erhalten.
- Alle Benutzenden, denen eine aktive Berechtigung zugewiesen ist, die sich jedoch nicht beim Dienst angemeldet haben, erhalten bis zu zwei E-Mail-Erinnerungen. (Dies gilt auch für vorhandene inaktive Benutzende vor dem Veröffentlichungsdatum.)
Diese Verbesserungen vereinfachen die Anmeldung, verringern Reibungspunkte und verbessern das Gesamtbenutzendenerlebnis.
Verfügbare Umgebungen: Kommerziell | Verfügbare Dienstebenen: Acrobat Sign Solutions | Konfigurationsumfang: Standardmäßig verfügbar; nicht konfigurierbar
|
Zuerst gemeldet: März 2025 – Aktualisiert April 2025 |
Aus aktueller Liste entfernt: Juni 2025 |
|---|
Ab der Version vom Mai 2025 wird Acrobat Sign strengere Grenzwerte für die Anzahl der Webhooks implementieren, die in Developer-Tier-Konten erstellt werden können.
Diese Einschränkungen wurden absichtlich gesetzt, um die Zuverlässigkeit der Webhook-Infrastruktur zu gewährleisten und sind besser für das Testen von Workflows geeignet.
|
Was sich ändert |
Vorherige Obergrenze |
Neue Begrenzung |
Beschreibung |
|---|---|---|---|
|
Anzahl der aktiven Webhooks, die pro Kanal erstellt wurden |
10 |
1 |
Für den Kanal ist pro Webhook-Abonnement-Ereignis 1 Webhook zulässig. |
|
Anzahl der aktiven Webhooks, die für ein Konto erstellt wurden |
100 |
2 |
Es sind 2 Webhooks auf Kontoebene pro Webhook-Abonnement-Ereignis zulässig. |
|
Anzahl der aktiven Webhooks, die pro Gruppe erstellt wurden |
100 |
2 |
Pro Gruppe sind für jedes Webhook-Abonnement-Ereignis jeweils 2 Webhooks auf Gruppenebene zulässig. |
|
Anzahl der aktiven Webhooks, die pro Vereinbarungsressource erstellt wurden |
50 |
1 |
Pro Vereinbarung ist pro Webhook-Abonnement-Ereignis 1 Webhook zulässig. |
|
Anzahl der aktiven Webhooks, die pro Konto erstellt wurden |
100 |
1 |
Pro Konto ist für jedes Webhook-Abonnement-Ereignis jeweils 1 Webhook zulässig. |
Verfügbare Umgebungen: Kommerziell | Verfügbare Dienstebenen: Entwicklerinnen und Entwickler | Konfigurationsumfang: standardmäßig aktiviert; nicht konfigurierbar
|
Zuerst veröffentlicht: März 2025 |
Aus aktueller Liste entfernt: April 2025 |
|---|
Acrobat Sign-Kunden können jetzt den Acrobat Sign Webhook-Service abonnieren, um proaktive Benachrichtigungen über Ausfälle, Störungen und Wartungsereignisse über das Adobe Status Portal zu erhalten.
Verwalte und füge Abonnements hier hinzu: Adobe Status Subscription Help.
Beachte bitte, dass der Adobe Acrobat Sign-Dienst unter der Überschrift Document Cloud aufgeführt wird:
|
Erstmals gemeldet: März 2025 |
Aus aktueller Liste entfernt: Juni 2025 |
|---|
In der Version vom Mai 2025 optimieren wir die GET /agreements-API, um die Antwortzeiten deutlich zu verkürzen – unsere internen Tests zeigen Verbesserungen um bis zu 10-mal.
Was ändert sich?
- Kleinere Seitengrößen: Um diese Verbesserungen zu unterstützen, haben wir die maximale Anzahl der pro Anfrage zurückgegebenen Vereinbarungen auf 500 reduziert, aber diese Grenze kann sich in zukünftigen Versionen ändern. Jede Antwort enthält Folgendes:
- Die tatsächlich zurückgegebene Anzahl der zurückgegebenen Verträge
- Ein Link zur nächsten Seite der Ergebnisse (falls verfügbar)
- Dynamische Anzahl der Ergebnisse: Du kannst immer noch eine bestimmte Anzahl von Verträgen anfordern, aber die API gibt so viele zurück, wie der Dienst bereitstellen kann. Jede Antwort enthält Folgendes:
Was ist zu erwarten?
In manchen Fällen kann es zu einer kleinen Verzögerung zwischen dem Erstellen einer Vereinbarung und dem Abrufen über die GET /agreements API kommen. Diese Verzögerung ist normalerweise sehr kurz; eine Folgeanfrage sollte den neuen Vertrag zurückgeben.
Verfügbare Umgebungen: Kommerziell, Behörden | Verfügbare Dienstebenen: Acrobat Sign-Dienste, Behörden | Konfigurationsumfang: Standardmäßig aktiviert; nicht konfigurierbar
|
Erstmals gemeldet: April 2025 |
Aus aktueller Liste entfernt: August 2025 |
|---|
Alle Konten, die den Acrobat Sign for Government-Service nutzen, erhalten Zugriff zur Aktivierung der neuen Request Signature-Umgebung sowie verschiedene kürzlich erstellte Funktionen, die davon abhängig sind:
- eWitnessing
- Eingeschränkter Zugriff auf Vereinbarungen
- Signaturtyp erzwingen
- Identitätsprüfung
- CC-Adressen pro Empfangspartei
- Die Empfangsliste und die Empfangseigenschaften können nach der Authoring-Erstellung bearbeitet werden
|
Zuerst veröffentlicht: September 2024 |
Aus aktueller Liste entfernt: Feb 2026 |
|---|
Handlungsbedarf
Alle Kunden, die die API verwenden, müssen ihre APIs so bald wie möglich aktualisieren, um die Version 6-Endpunkte zu nutzen und eine unterbrechungsfreie Verfügbarkeit sicherzustellen.
Versionen 1 bis 4 der Acrobat Sign REST-API wurden eingestellt und werden am 1. Dezember 2025 aus dem Dienst genommen.
Die Aktualisierung von APIs kann mit erheblichem Aufwand verbunden sein. Daher wird allen Kundinnen und Kunden dringend empfohlen, Umfang und Budget ihrer Aktualisierung so schnell wie möglich festzustellen, damit der Support vollständig eingebunden werden kann, um alle Fragen oder Probleme zu lösen, die vor dem Stichtag im Dezember 2025 auftreten.
Die REST-API v1 – 4 wurden zwar eingestellt, funktionieren aber weiterhin. Deine Anwendungen funktionieren bis zum 1. Dezember 2025 weiter, an dem die REST-API v1 – 4 entfernt werden.
Nach dem 1. Dezember 2025 werden Anwendungen, die auf Basis der REST-API v1 –4 erstellt wurden, nicht mehr funktionieren.
|
Zuerst veröffentlicht: April 2025 |
Aus aktueller Liste entfernt: Feb 2026 |
|---|
Alle Konten, die den Acrobat Sign for Government-Service nutzen, erhalten Zugriff zur Aktivierung der neuen Request Signature-Umgebung sowie verschiedene kürzlich erstellte Funktionen, die davon abhängig sind:
- eWitnessing
- Eingeschränkter Zugriff auf Vereinbarungen
- Signaturtyp erzwingen
- Identitätsprüfung
- CC-Adressen pro Empfangspartei
- Die Empfangsliste und die Empfangseigenschaften können nach der Authoring-Erstellung bearbeitet werden
|
Zuerst veröffentlicht: September 2024 – Aktualisiert April 2025 |
Aus aktueller Liste entfernt: Feb 2026 |
|---|
Die Webhook 2.0-Infrastruktur wurde für alle Kunden eingeführt und nachdem sie abgeschlossen ist, wurden die Unterzeichner-Benachrichtigungen eingestellt. Daher bietet der Parameter webhookNotificationApplicableUsers des Webhook-Payloads keine nützlichen Daten mehr und wird aus allen Webhook-Payloads entfernt.
Die Sandbox-Umgebung wird in der Version vom Juni aktualisiert.
Die Produktionsumgebungen werden in der Version vom Juli 2025 aktualisiert.
Die sendende Benutzer-ID und E-Mail findest du über die Parameter initiatingUserId und initiatingUserEmail in der Benachrichtigungs-Payload.
|
Erstmals gemeldet: August 2025 – Aktualisiert: Oktober 2025 |
Aus aktueller Liste entfernt: Feb 2026 |
|---|
Um die Systemstabilität zu erhalten und die Leistung zu verbessern, wird Acrobat Sign in der Version vom 4. November 2025 (Version 16.2.1) einen Abfrage-Schwellenwert einführen. Diese Änderung begrenzt, wie häufig Client-Anwendungen bestimmte API-Endpunkte abfragen können.
- Kundinnen und Kunden haben nach der Veröffentlichung von Version 16.2.1 zwei Monate Zeit, um die empfohlenen Änderungen beim Polling in ihrem Code zu implementieren. In diesem Zeitfenster wird das System nur die Schwellenwert-Ereignisse des Abfrageintervalls PROTOKOLLIEREN.
- Nach Dezember 2025 werden die Schutzrichtlinien für das Polling auf ERZWINGEN umgestellt und es werden Fehler für Benutzende ausgelöst.
Hochfrequente Abfragen erzeugen eine unnötige Last auf Backend-Systemen, was zu einer verminderten Leistung und längeren Antwortzeiten führt. API-Entwicklern wird empfohlen, für Echtzeit-Updates auf Webhooks umzusteigen.
Was sich ändert
Diese Abfragerichtlinie gilt für alle GET API-Endpunkte.
Beispiele für betroffene Endpunkte
Statusabfrage:
- GET /agreements/{agreementId) – Ruft den aktuellen Status eines Vertrags ab.
- GET /agreements/{agreementId)/documents/{documentId) – Ruft den Datei-Stream eines Dokuments innerhalb eines Vertrags ab.
Auflistung:
- GET /agreements – Ruft Verträge für Benutzende ab.
- GET /agreements/{agreementId)/events – Ruft Ereignisinformationen für einen Vertrag ab.
Es wird eine Begrenzung dafür eingeführt, wie oft effektive Benutzende denselben API-Aufruf an den Acrobat Sign-Dienst senden können. Ein Fehler wird zurückgegeben, wenn derselbe Aufruf innerhalb des minimalen Abfrageintervalls von derselben effektiven Person durchgeführt wird.
Details zur Abfragerichtlinie
- Minimales Objekt-Abfrageintervall (MOPI): Das Standard-MOPI variiert je nach Dienstebene und Anwendungstyp:
- Acrobat Sign-Partneranwendungen: Die MOPI für eine Partneranwendung wird durch die Ebende des Benutzerkontos bestimmt.
- GLOBAL/ENTERPRISE-Stufe: 3 Aufrufe pro Ein-Minuten-Intervall
- Alle anderen Stufen: 1 eindeutiger Aufruf pro Zehnminutenintervall
- Kundenanwendungen unter Global/Enterprise-Konten: Drei identische Aufrufe pro Ein-Minuten-Intervall.
- Kundenanwendungen unter Entwicklerkonten: Ein eindeutiger Aufruf pro 10-Minuten-Intervall.
- Acrobat Sign-Partneranwendungen: Die MOPI für eine Partneranwendung wird durch die Ebende des Benutzerkontos bestimmt.
- Doppelte Anfragen innerhalb des MOPI: Wenn dieselbe effektive Person identische GET-Anfragen (gleicher Pfad und Header) mehrmals innerhalb des MOPI stellt, als es seine Ebene zulässt, gibt das System Folgendes zurück:
- 304 Not Modified Statuscode für HTTP-bedingte Anfragen unter Verwendung eines ETags.
- 429 Zu viele Anfragen Statuscode mit einem Retry-After für andere Anfragen.
- ETag-Behandlung: Diese Richtlinie gilt, wenn ETag-Werte im Header für Endpunkte If-None-Match bereitgestellt werden, die bereits 304 Nicht modifiziert unterstützen.
Handlungsbedarf
Webhooks: Wenn deine Anwendung nahezu echtzeitnahe Updates benötigt, verwende Webhooks anstelle von Befragungen. Webhooks bieten eine effizientere und skalierbarere Möglichkeit, zeitnahe Updates zu erhalten.
Wenn Webhooks nicht implementiert werden können, sollten Applikationen clientseitige Caching-Mechanismen implementieren, um API-Antworten zu speichern und wiederzuverwenden. Wenn eine 304 Nicht modifiziert-Antwort empfangen wird, sollten die zwischengespeicherten Daten verwendet werden, anstatt einen weiteren API-Aufruf zu tätigen.
Kundinnen und Kunden haben nach der Veröffentlichung von Version 16.2.1 zwei Monate Zeit, um die empfohlenen Änderungen beim Polling in ihrem Code zu implementieren. In diesem Zeitfenster wird das System die Schwellenwert-Ereignisse des Abfrageintervalls PROTOKOLLIEREN.
Nach Dezember 2025 werden die Schutzrichtlinien für das Polling auf auf ERZWINGEN umgestellt, sodass Fehler für Benutzende ausgelöst werden.
Bitte wende dich an deinen CSM, wenn du Hilfe benötigst oder Fragen hast.
In der Sandbox-Umgebung werden die Richtlinien für das Polling am 17. September 2025 auf PROTOKOLLIEREN von Fehlern und am 25. September 2025 auf ERZWINGEN setzen.
|
Zuerst veröffentlicht: August 2025 |
Aus der aktuellen Liste entfernt: Feb 2026 |
|---|
Um die FedRAMP CSP-Anforderungen zu unterstützen, aktivieren wir das IPv6-Protokoll in unserer Acrobat Sign for Government Umgebung:
- 2001:489a:3102:4::160/124 (IPv6)
- 2001:489a:3102:4::150/124 (IPv6)
|
Zuerst veröffentlicht: September 2025 |
Aus der aktuellen Liste entfernt: Feb 2026 |
|---|
"Die Gültigkeitsprüfung der Spracheinstellungen wurde bei der Erstellung einer Vereinbarung über die API verschärft. "Wenn das Gebietsschema einer Vereinbarung nicht durch die Richtlinien des Kontos erlaubt ist, lehnt die API die Anfrage mit einem eindeutigen Fehler ab. "Dies reduziert unbeabsichtigte Sprachdiskrepanzen und hält die Empfängererfahrungen im Einklang mit den genehmigten Einstellungen.
Wer betroffen ist
- "Konten, die das Gebietsschema der Vereinbarung in API-Anfragen festlegen.
- "Konten, die verfügbare Gebietsschemata einschränken oder Änderungen des Gebietsschemas während des Sendens verbieten.
Was sich geändert hat
"Wenn die Einstellung DISPLAY_LOCALE_INFO_DURING_SEND aktiviert ist (GLOBAL-Ebene), erzwingt die API:
- "Das Gebietsschema der Vereinbarung muss in den AVAILABLE_LOCALES des Anwenders enthalten sein.
- "Wenn ALLOW_LOCALE_SELECTION_DURING_SEND falsch ist, muss das Gebietsschema der Vereinbarung mit dem AGREEMENT_LOCALE des Anwenders übereinstimmen.
Bei Verstößen schlägt POST /agreements fehl mit: „Gebietsschema ist entweder ungültig oder fehlt.
"Häufiger Fehler und wie man ihn behebt
Fehler: „Gebietsschema ist entweder ungültig oder fehlt.
- "Überprüfen Sie das in der API-Anfrage verwendete Gebietsschema (zum Beispiel en_US).
- "Bestätigen Sie, dass das Gebietsschema in AVAILABLE_LOCALES für den aufrufenden Anwender erscheint.
- "Wenn ALLOW_LOCALE_SELECTION_DURING_SEND falsch ist, stellen Sie sicher, dass das Gebietsschema der Anfrage mit AGREEMENT_LOCALE übereinstimmt.
- "Wenn Flexibilität über Regionen hinweg erforderlich ist, aktivieren Sie die Gebietsschema-Auswahl zum Sendezeitpunkt (siehe Erforderliche Aktion).
"Abwärtskompatibilität
- "Vor dieser Änderung konnten einige Anfragen mit nicht übereinstimmenden Gebietsschemata erfolgreich sein. "Solche Anfragen schlagen jetzt mit einem eindeutigen Fehler fehl, wenn die Gültigkeitsprüfungen nicht bestanden werden.
- "Keine API-Schema-Änderungen; das Validierungsverhalten ändert sich nur, wenn DISPLAY_LOCALE_INFO_DURING_SEND aktiviert ist.
Aktion erforderlich
"Administratoren und API-Integratoren sollten eines der folgenden Dinge tun:
- "Passen Sie das Gebietsschema in API-Anfragen an AVAILABLE_LOCALES an, und – wenn ALLOW_LOCALE_SELECTION_DURING_SEND falsch ist – stimmen Sie es genau mit AGREEMENT_LOCALE ab
- oder -
- "Erlauben Sie die Gebietsschema-Auswahl zum Sendezeitpunkt, indem Sie Folgendes einstellen:
- "ALLOW_LOCALE_SELECTION_DURING_SEND = wahr
- CAN_CHANGE_UI_LOCALE = wahr
|
Zuerst veröffentlicht: Dezember 2025 |
Aus der aktuellen Liste entfernt: Feb 2026 |
|---|
Adobe Acrobat Sign tauscht das Adobe Acrobat Sign SSL-Zertifikat am 7. Januar 2026 aus.
Handlungsbedarf
- Wenn du über benutzerdefinierte Integrationen mit Acrobat Sign verfügst, die REST-API verwenden, und für diese Integrationen der vorhandene öffentliche Schlüssel „angeheftet“ ist, musst du darüber hinaus nichts tun.
- Wenn du Acrobat Signs SSL-Zertifikate für SSO verwendest oder das Zertifikat selbst anheftest (oder andere Methoden verwendest), findest du die neuen Acrobat Sign SSL-Zertifikate in den Adobe Acrobat Sign Systemanforderungen.
- Wenn deine SSO-Konfiguration mehrere öffentliche Zertifikate/Chains unterstützt, kannst du die neuen Zertifikate jetzt hinzufügen und das alte öffentliche Zertifikat/die alte Chain nach der Januar-Änderung aus deiner Konfiguration entfernen.
- Wenn dein SSO nicht mehrere öffentliche Zertifikate/Chains unterstützt, musst du deine SSL-Änderung am 7. Januar 2026 mit Acrobat Sign synchronisieren.
Die neuen SSL-Zertifikate sind ab dem 7. Januar 2026 aktiv.
|
Zuerst veröffentlicht: März 2026 |
Aktuell Aus der aktuellen Liste entfernt: Juni 2026 |
|---|
Am 11. April 2026 um 19:30 Uhr Pacific Time findet eine geplante Datenbankwartung statt. Das Wartungsfenster soll voraussichtlich bis zu 30 Minuten dauern.
Diese Wartungsarbeiten betreffen alle Acrobat Sign-Umgebungen und gelten nur für von Adobe verwaltete Konten (IMS). Konten, die ihre Benutzenden direkt in Acrobat Sign verwalten, sind davon nicht betroffen.
Während dieser Zeit:
- Die Erstellung neuer Konten und die Einrichtung von Benutzenden wird verzögert.
- Bei einer begrenzten Anzahl von Benutzenden können Probleme bei der Anmeldung auftreten.
- Transaktionsanforderungen zur Kontonutzung aus administrativen Adobe-Oberflächen können fehlschlagen, was die Zuweisung von Berechtigungen vorübergehend verhindern kann.
Alle betroffenen Services sollen nach Abschluss der Wartung wieder normal funktionieren.
|
Zuerst veröffentlicht: März 2026 |
Aus der aktuellen Liste entfernt: Juni 2026 |
|---|
Die von der API zurückgegebenen Dokument-IDs verwenden jetzt ein 16-Bit-Kodierungsformat anstelle des vorherigen 12-Bit-Kodierungsformats und können nachgestellte Sternchen als Teil des zurückgegebenen Wertes enthalten. Acrobat Sign akzeptiert Dokument-IDs mit oder ohne diese nachgestellten Zeichen, jedoch können einige Anwendungen das erweiterte Format möglicherweise nicht korrekt verarbeiten, was sich auf den Abruf oder die Anzeige von Dokumenten auswirken kann.
Diese Aktualisierung spiegelt eine Änderung in der Verarbeitung von Dokument-IDs im Service wider. Wenn deine Integration Dokumente mithilfe der von der API zurückgegebenen Dokument-IDs abruft, überprüfe die aktuelle Logik, um sicherzustellen, dass sie das längere ID-Format unterstützt und den zurückgegebenen Wert unverändert akzeptieren kann. Falls erforderlich, können nachgestellte Sternchen vor einem erneuten Versuch der Anfrage entfernt werden.
Der direkte Zugriff über Acrobat Sign sollte voraussichtlich nicht beeinträchtigt sein.
|
Zuerst veröffentlicht: Februar 2026 – Aktualisiert April 2026 |
Aus der aktuellen Liste entfernt: Juni 2026 |
|---|
Die Acrobat Sign-Startseite wird neu gestaltet, um das Starten von Vereinbarungen, Überwachen von Aktivitäten und den Zugriff auf wichtige Funktionen zu erleichtern, einschließlich der Möglichkeit, kürzlich gesendete Vereinbarungen zu kopieren, Aktionskacheln in einer intuitiveren Reihenfolge anzuzeigen, aktuelle und Auf dich wartend-Elemente schnell zu identifizieren und ein optimiertes Banner Neue Funktionen zu erleben, das die visuelle Übersichtlichkeit verbessert, Benutzende schneller zum Ergebnis führt, verpasste Vereinbarungen reduziert, und navigieren Sie zu einem fokussierten Startseiten-Erlebnis.
Die neue Startseite wird 10 Tage nach der Veröffentlichung veröffentlicht:
Datum |
Shards |
5. Mai 2026 |
IN1, JP1, AU1, SG1 |
11. Mai 2026 |
EU1, EU2, NA4 |
14. Mai 2026 |
NA1, NA2, NA3 |
Anmerkung
Der Rollout-Zeitplan dient als Richtlinie und kann im Verlauf des Rollouts angepasst werden.
|
Zuerst veröffentlicht: März 2026 |
Aus der aktuellen Liste entfernt: Juni 2026 |
|---|
Seit der Veröffentlichung von Version 17.0.1 am 17. März wird auf der Registerkarte Zugriffstoken im Menü Persönliche Einstellungen das Ablaufdatum für jeden Integrationsschlüssel angezeigt. Diese Aktualisierung verbessert die Transparenz der Schlüsselverwaltung, da sie Schlüsselinhabern ermöglicht, den Ablauf eines Schlüssels einzusehen.
Integrationsschlüssel haben eine 10-jährige Gültigkeitsdauer. Nach dem Ablaufdatum kann der Schlüssel nicht mehr verwendet werden und muss durch einen neuen Schlüssel ersetzt werden.
Diese Änderung beeinflusst nicht, wie bestehende Schlüssel funktionieren, und ändert nicht den Schlüssellebenszyklus. Sie zeigt nur das Ablaufdatum in der Schnittstelle an, damit Administratoren das Alter der Schlüssel überwachen und einen Austausch im Voraus planen können.
Es ist keine Aktion von Ihrer Seite erforderlich. Administrierende sollten ihre Integrationsschlüssel regelmäßig überprüfen und solche ersetzen, die sich dem Ablaufdatum nähern, um Dienstunterbrechungen zu vermeiden.
|
Zuerst veröffentlicht: März 2026 |
Aus der aktuellen Liste entfernt: Juni 2026 |
|---|
Ab der Version vom 5. Mai 2026 werden Audit-Berichte die verwendete Signaturmethode aufzeichnen, wenn ein Unterzeichner seine Signatur anbringt.
Für jedes ESIGNED- und DIGSIGNED-Ereignis weist das Audit-Protokoll aus, ob Unterzeichnende eine desktopbasierte Signaturmethode (TYP, ZEICHNUNG, BILD) oder eine mobilbasierte Signaturmethode (MOBILGERÄTE_TYP, MOBIL_ZEICHNUNG, MOBIL_BILD) verwendet haben.
Diese Aktualisierung verbessert die Compliance-Sichtbarkeit, indem Administratoren und Compliance-Teams die Signaturmethode direkt im Audit-Bericht überprüfen können, wodurch Mehrdeutigkeiten reduziert und unnötige Ablehnungen von Vereinbarungen während Überprüfungs- und Auditprozessen minimiert werden. Diese Aktualisierung ist standardmäßig für alle Kunden aktiviert, ohne Konfigurationsoption.
Anmerkung
Die Anwendung einer Signatur ausschließlich mit einem Stempel wird nicht zu den erfassten Signaturtypen gezählt.
|
Zuerst veröffentlicht: Dezember 2025 – Aktualisiert: Februar 2026 |
Aus der aktuellen Liste entfernt: Juni 2026 |
|---|
Die Anmeldeseite von Acrobat Sign wird im Rahmen der Version 17.0, die für den 3. Februar 2026 geplant ist, für alle Benutzenden aktualisiert. - Der neue Anmeldungsprozess bietet ein saubereres und konsistenteres Erlebnis, indem alle Nutzer aufgefordert werden, ihre E-Mail-Adresse anzugeben und sonst nichts. Sobald die E-Mail-Adresse akzeptiert wurde, wird auf das Benutzerkonto verwiesen, und auf der Folgeseite werden die Authentifizierungsoptionen angezeigt, für die das Konto konfiguriert ist. Dadurch entfallen unnötige Schritte und veraltete Bildschirme. Das macht das Anmelden für alle schneller, einfacher und intuitiver.
- Im Rahmen des neuen Anmeldeerlebnisses gilt für Acrobat Sign Enterprise‑Benutzende, die sich direkt über die Weboberfläche anmelden, nun ein Limit von 64 Zeichen für den lokalen Teil der E‑Mail‑Adresse (den Abschnitt vor dem „@“-Symbol).
Dieses aktualisierte Anmeldeerlebnis wird phasenweise von der Acrobat Sign-Serverumgebung ausgerollt. Der Rollout-Zeitplan ist unten dargestellt:
|
Acrobat Sign-Umgebung |
Rollout-Datum |
|
IN1 (Indien) SG1 (Singapur) |
03. Februar 2026 |
|
AU1 (Australien) NA3 (Nordamerika) |
10. Februar 2026 |
|
JP1 (Japan) |
17. Februar 2026 |
|
EU2 (Europa) NA4 (Nordamerika) |
02. März 2026 |
|
EU1 (Europa) NA2 (Nordamerika) |
05. März 2026 |
|
NA1 (Nordamerika) |
10. März 2026 |
Anmerkung
Der Rollout-Zeitplan dient als Richtlinie und kann im Verlauf des Rollouts angepasst werden.
|
Zuerst veröffentlicht: Februar 2026 |
Aus der aktuellen Liste entfernt: Juni 2026 |
|---|
