Eerst gerapporteerd: augustus 2024
Laatst bijgewerkt op
9 feb. 2026
De technische meldingen van Adobe Sign zijn hieronder gerangschikt met de oudste update bovenaan en doorlopend in de tijd terwijl je naar beneden scrolt op de pagina.
|
|
Verwijderd uit huidige lijst: januari 2025 |
|---|
De verouderde header Accept-Charset wordt met de release van november 2024 uit alle webhook- en callbackmeldingen verwijderd.
Alle klanten die van deze deze header gebruikmaken, moeten hun code opnieuw instellen om rekening te houden met het ontbreken van deze header.
|
Eerst gerapporteerd: september 2024 |
Verwijderd uit huidige lijst: januari 2025 |
|---|
|
Eerst gemeld: november 2024 |
Verwijderd uit huidige lijst: januari 2025 |
|---|
Met de release van november 2024 zijn de bewerkbare labels in de designer voor aangepaste workflows beperkt tot 100 tekens. Deze limiet wordt geëvalueerd wanneer de workflow wordt gemaakt of bijgewerkt.
Bestaande workflows met labels van meer dan 100 tekens kunnen nog steeds worden verzonden, maar als de workflow wordt bijgewerkt, moet het label worden teruggezet naar 100 tekens of minder voordat de workflow kan worden opgeslagen. Labels die niet aan deze limiet voldoen, worden rood weergegeven zodat ze opvallen.
Nieuwe workflows waarschuwen voor de labellimiet voordat ze worden opgeslagen.
Actie vereist
Het wordt aanbevolen dat beheerders met controle over aangepaste workflows elke workflow openen en controleren of er geen fouten in hun sjabloon staan.
|
Eerst gemeld: november 2024 |
Verwijderd uit huidige lijst: februari 2025 |
|---|
De nieuwe ervaring voor ontvangers bevat verbeteringen voor ondertekenen voor zowel desktop als mobiele web browsers.Deze nieuwe ervaring wordt in de eerste maanden van 2025 uitgerold, maar in de sandboxomgeving zal deze beschikbaar zijn in de eerste week van december 2024.
|
Eerst gemeld: december 2024 |
Verwijderd uit huidige lijst: februari 2025 |
|---|
Adobe Acrobat Sign rouleert het Adobe Acrobat Sign SSL-certificaat op 22 januari 2025.
Daarnaast wordt een nieuw SSL-certificaat geïmplementeerd ter ondersteuning van de WAF-netwerkwijzigingen die in januari 2025 worden doorgevoerd. Dit nieuwe certificaat heeft rechtstreeks invloed op de toegang tot de Acrobat Sign-service en moet worden geïnstalleerd voordat de WAF online gaat.
Actie vereist
- In elk klantaccount dat expliciet netwerkactiviteiten beveiligt, moet het nieuwe WAF SSL-certificaat in de lijst met opgeslagen certificaten zijn opgenomen.
- Als u aangepaste integraties met Acrobat Sign hebt met behulp van de SOAP- of REST-API's en als een van deze integraties de bestaande openbare sleutel heeft 'vastgezet', is geen verdere actie vereist.
- Als je de SSL-certificeringen van Acrobat Sign gebruikt voor SSO, of als je het certificaat zelf vastpint (of andere methoden gebruikt), kun je de nieuwe SSL-certificeringen van Acrobat Sign vinden in de systeemvereisten van Adobe Acrobat Sign.
- Als uw SSO-configuratie meerdere openbare certificaten/ketens ondersteunt, kunt u de nieuwe certificaten nu toevoegen en de oude openbare certificaten/ketens na de overstap van januari uit uw configuratie verwijderen.
- Als uw SSO niet meerdere openbare certificaten/ketens ondersteunt, moet u de SSL-switch op donderdag 22 januari 2025 met Acrobat Sign synchroniseren.
De nieuwe SSL-certificaten worden actief op 22 januari 2025.
|
Eerst gerapporteerd: september 2024 - Bijgewerkt: februari 2025 |
Verwijderd uit huidige lijst: maart 2025 |
|---|
Voor een betere beveiliging en robuustheid van de Adobe Acrobat Sign-service, beginnen we in februari 2025 met het uitrollen van netwerkwijzigingen, waaronder die voor een webapplicatiefirewall (WAF). Deze wijzigingen zorgen ervoor dat verkeer naar Acrobat Sign-toepassingsservers wordt gerouteerd via de WAF-service. Deze routering is voor de meeste klanten onzichtbaar. Gebruik zal geen invloed hebben op de toegang tot Acrobat Sign vanuit Adobe-toepassingen of -integraties.
Actie vereist
Geen actie vereist.
Deze wijziging is in de meeste gevallen niet van invloed op de klantintegratie, omdat de Acrobat Sign-API- en API-domeinnamen niet veranderen. Deze oplossing is achterwaarts compatibel met de gepubliceerde IP-bereiken.
Klanten die hun beveiligingsapparaten hebben bijgewerkt, hoeven geen configuraties te herstellen en hoeven ook geen andere wijzigingen meer aan te brengen.
Het huidige updateschema is:
- Productiesandbox wordt op 24 februari 2025 bijgewerkt.
- Productieshards: IN1, JP1, AU1 en SG1 worden op 3 maart 2025 bijgewerkt.
- Productieshards: NA2, NA3 en EU2 worden op 6 maart 2025 bijgewerkt.
- Productieshards: NA1, NA4 en EU1 worden op 11 maart 2025 bijgewerkt.
-
Toegang tot Acrobat Sign: inkomend en uitgaand
Acrobat Sign blijft ondersteuning bieden voor de lijst met inkomende IP-serveradressen, in tegenstelling tot wat eerder is aangekondigd.
De ingaande en uitgaande IP-serveradressen blijven functioneren, zoals aangegeven op de pagina Systeemvereisten voor Acrobat Sign. -
Waarom voert Acrobat Sign deze wijzigingen door?
Het gebruik van een WAF verbetert de bescherming van Acrobat Sign tegen kwaadaardig verkeer en helpt ons beter te voldoen aan de vereisten op het gebied van beveiliging, robuustheid en naleving.
-
Ik heb een aangepaste integratie in Acrobat Sign. Heeft dit gevolgen voor mijn toepassing?
Nee, we verwachten niet dat dit een negatieve impact heeft op integraties.
-
Zijn er nieuwe IP-adreslijsten die kunnen worden vervangen?
Nee.
De informatie op de pagina systeemvereisten voor Acrobat Sign blijft accuraat. -
Mijn organisatie heeft netwerkfiltering geïmplementeerd met behulp van de gepubliceerde domeinlijst van Acrobat Sign voor verkeer van ons bedrijfsnetwerk. Heeft dit gevolgen voor ons?
Nee.
De netwerkwijzigingen die hier worden beschreven, hebben geen invloed op de domeinlijst van Acrobat Sign, zoals gedocumenteerd op de pagina systeemvereisten voor Acrobat Sign.Het filteren op domeinniveau wordt niet beïnvloed. -
Mijn organisatie maakt gebruik van IP-adresvalidatie voor e-mailbezorging vanaf Acrobat Sign-servers. Heeft dit gevolgen voor ons?
Nee.
De IP-bereiken voor uitgaande mailrelays, zoals vermeld op de pagina systeemvereisten voor Acrobat Sign, wijzigen niet. -
Mijn organisatie heeft ons Acrobat Sign-account geconfigureerd om toegang te beperken tot onze eigen IP-adressen. Heeft dit gevolgen voor ons?
Nee.
Acrobat Sign kan worden geconfigureerd om inkomend traffic te valideren tegen door de klant gekozen IP-adressen, zoals beschreven op de pagina toegang tot je account beperken met IP-adresbereiken.Dergelijk gebruik wordt niet beïnvloed door deze wijziging. -
Mijn organisatie heeft netwerkfiltering geïmplementeerd met behulp van de gepubliceerde lijst met inkomende IP-adressen van Acrobat Sign. Heeft dit gevolgen voor ons?
Nee.
De nieuwe WAF-configuratie is achterwaarts compatibel met de bestaande netwerkarchitectuur. Er is dus geen extra aanpassing van uw beveiligingsapparaten nodig.
Opmerking:Houd er rekening mee dat dit verwijst naar het filteren op IP-niveau voor de omgeving waarin uw toepassing wordt gehost. Filteren op domeinniveau wordt niet beïnvloed.
-
Ik gebruik de Salesforce-integratie met expliciet geconfigureerde, toegestane IP-lijsten. Moet ik iets doen?
Nee.
Voor de installatie van een WAF zijn momenteel geen wijzigingen voor bestaande Salesforce-installaties vereist.
De bestaande configuratie en het bestaande proces zoals beschreven in de Help-documentatie blijft gelijk en beheerders moeten alle stappen voor toegestane IP-lijsten volgen.
ISV-partners en ingesloten partners moeten contact met hun succesmanager opnemen voor eventuele verdere vragen.
|
Eerst gerapporteerd: november 2024 - Bijgewerkt: januari 2025 |
Verwijderd uit huidige lijst: maart 2025 |
|---|
Afzenders kunnen een extra weergave van overeenkomsten voor mobiele ontvangers bieden die alleen de beschikbare overeenkomstvelden voor de ontvanger vermeldt.
Afzenders kunnen de lijst met velden naar wens indelen en velden groeperen in logische secties, zodat ondertekenaars met zo min mogelijk scrollen door de veldinvoer kunnen navigeren.
Ontvangers kunnen de mobiele veldenlijst of de originele PDF-weergave bekijken, waarbij de velden in de documentinhoud zijn geplaatst.
Deze functie is gepland voor release:
- Wordt op 11 december 2024 geïmplementeerd in de sandboxomgeving
- Wordt op 4 maart 2025 in de productieomgeving geïmplementeerd
|
Eerst gerapporteerd: mei 2024 |
Verwijderd uit huidige lijst: maart 2025 |
|---|
De optie om een extern station te gebruiken voor het uploaden van bestanden is in de nieuwe ervaring voor Handtekening aanvragen beperkt tot OneDrive.
Het wordt aanbevolen dat klanten die andere opties gebruiken voor het uploaden van bestanden, de voor de leverancier specifieke applicatie gebruiken om een netwerkstation te bieden dat toegankelijk is via de native bestandenkiezer op het lokale systeem van de gebruiker.
- 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
|
Eerst gerapporteerd: mei 2024 |
Verwijderd uit huidige lijst: april 2025 |
|---|
Actie vereist
Alle integraties en toepassingen die de Adobe Acrobat Sign SOAP API gebruiken, moeten vóór de datum van uitschakeling naar de nieuwste REST API V6 worden gemigreerd om de voortdurende werking te garanderen.
Toegang tot de SOAP-API wordt op 1 maart 2025 verwijderd voor alle ingesloten partners.
Om een blijvende functie te garanderen moeten alle ingesloten partners vóór 1 maart 2025 met behulp van de Adobe Acrobat Sign SOAP-API migreren naar de nieuwste REST-API V6.
Raadpleeg de REST v6- en migratiedocumentatie als referentie:
- Methoden voor Adobe Acrobat Sign REST API versie 6
- Migreren van SOAP
Neem voor vragen contact op met uw speciale Adobe Acrobat Sign PSM.
Opmerking:
Deze update is alleen van toepassing op de Commerciële versie van de Acrobat Sign-service. Government Cloud-accounts worden niet beïnvloed.
Deze update geldt alleen voor de pagina Verzenden (Verzoek e-handtekeningen).Workflows voor Gestructureerde zelfondertekening zijn nog niet opgenomen.
|
Eerst gerapporteerd: maart 2024 - Bijgewerkt: januari 2025 |
Verwijderd uit huidige lijst: april 2025 |
|---|
Vanaf de release van april 2025 wordt de moderne omgeving voor het aanvragen van handtekeningen de standaardervaring bij het maken van een nieuwe overeenkomst.
- Gebruikers kunnen niet meer wisselen tussen de nieuwe en klassieke omgeving doordat wisselkoppelingen worden uitgeschakeld.
- Beheerders kunnen nog steeds de klassieke ervaring inschakelen en wisselkoppelingen herstellen via het beheerdersmenu.
- Klanten die de Notarize-integratie gebruiken, merken niets van deze wijziging.
|
Eerst gerapporteerd: maart 2024 - Bijgewerkt april 2025 |
Verwijderd uit huidige lijst: april 2025 |
|---|
Opmerking:
Deze update is alleen van toepassing op de Commerciële versie van de Acrobat Sign-service. Government Cloud-accounts worden niet beïnvloed.
Vanaf de release van april 2025 wordt de moderne Request Signature-omgeving de standaardervaring die beschikbaar is bij het maken van een nieuw sjabloon voor In bulk verzenden.
- Gebruikers kunnen niet meer terugschakelen naar de klassieke omgeving.
- Beheerders hebben de optie om de klassieke ervaring in te schakelen en schakelkoppelingen te herstellen via het beheermenu.
|
Eerst gerapporteerd: februari 2025 |
Verwijderd uit huidige lijst: april 2025 |
|---|
Het tabblad Account, beschikbaar voor Acrobat Sign-accountbeheerders, krijgt de nieuwe naam Beheerder.
- Deze update is uitsluitend van toepassing op de autonome Acrobat Sign-omgeving (Acrobat Sign Solutions en Acrobat Sign voor Government).
- De update wordt in april 2025 geïmplementeerd voor de commerciële omgeving en in mei 2025 voor de overheidsomgeving.
Houd er rekening mee dat deze wijziging puur cosmetisch is. Er zijn geen functionele wijzigingen, alleen updates aan de tabbladlabels.
Opmerking:
Het label Groep voor beheerders op groepsniveau verandert niet.
|
Eerst gerapporteerd: maart 2025 |
Verwijderd uit huidige lijst: april 2025 |
|---|
- Verbeterde gebruikersaanmeldingservaring : Acrobat Sign heeft het aanmeldings- en verificatieproces gestroomlijnd via het Adobe Identity Management-systeem (IMS).
- Het gebruikersorganisatieprofiel wordt tijdens het aanmeldingsproces automatisch geselecteerd voor degenen die recht hebben op de Acrobat Sign-service (de aanvraag wordt geïdentificeerd als afkomstig van een Acrobat Sign-bron)
- Gebruikers die fouten tegenkomen tijdens het aanmelden, hebben koppelingen in hun foutberichten om contact op te nemen met hun Acrobat Sign-beheerders voor hulp.
- Alle gebruikers aan wie een actieve machtiging is toegewezen, maar die zich nog niet hebben aangemeld bij de service, krijgen maximaal twee e-mailherinneringen. (Dat geldt ook voor bestaande inactieve gebruikers vóór de releasedatum )
Deze verbeteringen vereenvoudigen het aanmelden, verminderen frictie en verbeteren de algemene gebruikerservaring.
Beschikbare omgevingen: Commercieel | Beschikbare serviceniveaus: Acrobat Sign Solutions | Configuratiebereik: Standaard ingeschakeld; Niet configureerbaar
|
Eerst gerapporteerd: maart 2025 - Bijgewerkt: april 2025 |
Verwijderd uit huidige lijst: juni 2025 |
|---|
Na de release van mei 2025 gaat Acrobat Sign strengere limieten implementeren voor het aantal webhooks dat wordt gemaakt in accounts op Developer-niveau.
Deze beperkingen zijn opzettelijk gekozen om de vertrouwbaarheid van de webhook-infrastructuur te garanderen en beter af te stemmen op testworkflows.
|
Wat verandert er? |
Vorige limiet |
Nieuwe limiet |
Beschrijving |
|---|---|---|---|
|
Aantal actieve webhooks per kanaal gemaakt |
10 |
1 |
Er is voor het kanaal 1 webhook per webhook-lidmaatschapgebeurtenis toegestaan. |
|
Aantal actieve webhooks dat voor een account is gemaakt |
100 |
2 |
Er zijn 2 webhooks op accountniveau toegestaan per webhook-lidmaatschapgebeurtenis. |
|
Aantal actieve webhooks per groep gemaakt |
100 |
2 |
Er zijn 2 webhooks op groepsniveau per groep per webhook-lidmaatschapgebeurtenis toegestaan. |
|
Aantal actieve webhooks dat per overeenkomstbron is gemaakt |
50 |
1 |
Er is 1 webhook per overeenkomst per webhook-lidmaatschapgebeurtenis toegestaan. |
|
Aantal actieve webhooks per gebruiker gemaakt |
100 |
1 |
Er is 1 webhook per gebruiker per webhook-lidmaatschapsgebeurtenis toegestaan. |
Beschikbare omgevingen: Commercial | Beschikbare serviceniveaus: Ontwikkelaar | Configuratiebereik: Standaard ingeschakeld; Niet configureerbaar
|
Eerst gerapporteerd: maart 2025 |
Verwijderd uit huidige lijst: april 2025 |
|---|
Acrobat Sign-klanten kunnen zich nu abonneren op de Acrobat Sign-webhookservice om proactieve meldingen te ontvangen over storingen, onderbrekingen en onderhoudsgebeurtenissen via de Adobe Status Portal.
Hier kunt u lidmaatschappen beheren en toevoegen: Help voor Adobe Status-lidmaatschappen.
Houd er rekening mee dat de Adobe Acrobat Sign -service wordt vermeld onder de kop Document Cloud:
|
Eerst gerapporteerd: maart 2025 |
Verwijderd uit huidige lijst: juni 2025 |
|---|
In de release van mei 2025 optimaliseren we de GET /agreements-API om de responstijden aanzienlijk te verkorten. Onze interne tests laten verbeteringen tot wel 10 keer zien.
Wat gaat er veranderen?
- Smallere paginagroottes: om deze verbeteringen te ondersteunen hebben we het maximale aantal overeenkomsten per aanvraag verlaagd naar 500, maar dit limiet kan in toekomstige releases veranderen. Elke reactie omvat:
- Het daadwerkelijke aantal geretourneerde overeenkomsten
- Een koppeling naar de volgende pagina met resultaten (indien beschikbaar)
- Dynamische resultaattelling: u kunt nog steeds een specifiek aantal overeenkomsten aanvragen, maar de API retourneert zoveel mogelijk als de service kan bieden. Elke reactie omvat:
Wat kunt u verwachten?
In sommige gevallen kan een kleine vertraging optreden tussen het maken van een overeenkomst en het ophalen ervan met behulp van de GET /agreements-API. Deze vertraging is meestal zeer kort. Een vervolgverzoek moet de nieuwe overeenkomst retourneren.
Beschikbare omgevingen: Commercial, Government | Beschikbare serviceniveaus: Acrobat Sign Services, Government | Configuratiebereik: Standaard ingeschakeld; Niet configureerbaar
|
Eerst gerapporteerd: april 2025 |
Verwijderd uit huidige lijst: augustus 2025 |
|---|
Alle accounts die gebruikmaken van de service Acrobat Sign for Government krijgen toegang om de nieuwe Request Signature-omgeving in te schakelen, samen met verschillende recent gemaakte functies die hiervan afhankelijk zijn:
- eWitnessing
- Beperkte toegang tot overeenkomsten
- Handtekeningtype afdwingen
- Identiteitscontrole
- CC's per ontvanger
- De lijst met ontvangers en de eigenschappen van ontvangers kunnen na authoring worden bewerkt
|
Eerst gerapporteerd: september 2024 |
Verwijderd uit huidige lijst: feb 2026 |
|---|
Actie vereist
Alle klanten die de API gebruiken moeten hun API's zo snel mogelijk bijwerken om de versie 6-eindpunten te gebruiken om ononderbroken beschikbaarheid te garanderen.
Versies 1 tot 4 van de Acrobat Sign REST-API zijn verouderd en worden op 1 december 2025 buiten gebruik gesteld.
Het bijwerken van API's kan veel moeite kosten, dus wordt alle klanten sterk aanbevolen om hun update zo snel mogelijk uit te voeren en te beheren, zodat ondersteuning volledig kan worden betrokken bij het oplossen van vragen of problemen die optreden vóór de uiterste datum in december 2025.
Hoewel REST-API's v1-4 zijn verouderd, blijven ze functioneren en blijven uw applicaties werken tot 1 december 2025, wanneer de REST-API's v1-4 worden verwijderd.
Na 1 december 2025 zullen applicaties die zijn gebouwd voor de REST API v1-4, niet meer functioneren.
|
Eerst gemeld: april 2025 |
Verwijderd uit huidige lijst: feb 2026 |
|---|
Alle accounts die gebruikmaken van de service Acrobat Sign for Government krijgen toegang om de nieuwe Request Signature-omgeving in te schakelen, samen met verschillende recent gemaakte functies die hiervan afhankelijk zijn:
- eWitnessing
- Beperkte toegang tot overeenkomsten
- Handtekeningtype afdwingen
- Identiteitscontrole
- CC's per ontvanger
- De lijst met ontvangers en de eigenschappen van ontvangers kunnen na authoring worden bewerkt
|
Eerst gerapporteerd: september 2024 - Bijgewerkt: april 2025 |
Verwijderd uit huidige lijst: feb 2026 |
|---|
De Webhook 2.0-infrastructuur is uitgerold voor alle klanten en om die reden zijn meldingen aan ondertekenaars beëindigd. Daardoor biedt de parameter webhookNotificationApplicableUsers van de Webhook-payload geen bruikbare gegevens meer en wordt deze verwijderd uit alle Webhook-payloads.
De productieomgevingen worden bijgewerkt in de release van juni.
De productieomgevingen worden bijgewerkt in de release van juli 2025.
De verzendende gebruikers-ID en e-mail zijn te vinden met behulp van de parameters initiatingUserId en initiatingUserEmail in de meldingspayload.
|
Eerst gerapporteerd: augustus 2025 - Bijgewerkt oktober 2025 |
Verwijderd uit huidige lijst: feb 2026 |
|---|
Om de systeemstabiliteit te behouden en de prestaties te verbeteren, zal Acrobat Sign een polling-drempel introduceren in de release van 4 november 2025 (versie 16.2.1). Deze wijziging beperkt hoe vaak clientapplicaties specifieke API-eindpunten kunnen pollen.
- Klanten hebben twee maanden na de 16.2.1 release om de aanbevolen polling-wijzigingen in hun code te implementeren. Tijdens dit tijdsvenster zal het systeem ALLEEN de polling-interval drempelgebeurtenissen LOGGEN.
- Na december 2025 worden de polling-beschermingsregels omgezet naar AFDWINGEN en zullen de fouten beginnen te triggeren voor gebruikers.
Hoogfrequent pollen creëert een onnodige belasting voor backend-systemen, wat resulteert in verminderde prestaties en tragere responstijden. API-ontwikkelaars worden aangemoedigd om over te stappen op webhooks voor realtime updates.
Wat er verandert
Dit polling-beleid is van toepassing op alle GET API-eindpunten.
Voorbeelden van getroffen eindpunten
Statusophaling:
- GET /agreements/{agreementId) – Haalt de huidige status van een overeenkomst op.
- GET /agreements/{agreementId)/documents/{documentId) – Haalt de bestandsstroom op van een document binnen een overeenkomst.
Lijsten:
- GET /agreements – Haalt overeenkomsten op voor de gebruiker.
- GET /agreements/{agreementId)/events – Haalt gebeurtenisinformatie op voor een overeenkomst.
Er wordt een limiet toegepast op hoe vaak de effectieve gebruiker dezelfde API-aanroep naar de Acrobat Sign-service kan doen. Er wordt een fout geretourneerd als dezelfde aanroep binnen het minimale pollinginterval door dezelfde effectieve gebruiker wordt gedaan.
Details pollingbeleid
- Minimum Object Polling Interval (MOPI): De standaard MOPI varieert afhankelijk van de servicelaag en app-typen:
- Acrobat Sign partner-apps: De MOPI voor een partner app wordt bepaald door de laag van het account van de gebruiker.
- GLOBAL/ENTERPRISE-laag: 3 oproepen per interval van één minuut
- Alle andere lagen: 1 unieke oproep per interval van tien minuten
- Klant-apps onder Global/Enterprise-accounts: Drie identieke oproepen per interval van één minuut.
- Klant-apps onder Developer-accounts: Eén unieke oproep per interval van 10 minuten.
- Acrobat Sign partner-apps: De MOPI voor een partner app wordt bepaald door de laag van het account van de gebruiker.
- Dubbele verzoeken binnen MOPI: Als dezelfde effectieve gebruiker identieke get-verzoeken maakt (hetzelfde pad en headers) meer dan hun tier toestaat binnen de MOPI, retourneert het systeem:
- 304 Niet gewijzigd statuscode voor HTTP-voorwaardelijke verzoeken met een ETag.
- 429 Te veel verzoeken statuscode met een retry-after voor andere verzoeken.
- ETag-verwerking: Dit beleid is van toepassing wanneer ETag-waarden worden verstrekt in de If-None-Match header voor eindpunten die al 304 Niet gewijzigd ondersteunen.
Actie vereist
Webhooks: Als je applicatie bijna realtime updates vereist, gebruik dan webhooks in plaats van polling. Webhooks bieden een efficiëntere en schaalbaardere manier om tijdige updates te ontvangen.
Als webhooks niet kunnen worden geïmplementeerd, moeten applicaties client-side caching-mechanismen implementeren om API-responses op te slaan en opnieuw te gebruiken. Wanneer een 304 Niet gewijzigd response wordt ontvangen, moeten de gecachte gegevens worden gebruikt in plaats van een nieuwe API-aanroep te doen.
Klanten hebben twee maanden na de 16.2.1 release om de aanbevolen polling-wijzigingen in hun code te implementeren. Gedurende deze periode zal het systeem de polling-intervaldrempelgebeurtenissen LOGGEN.
Na december 2025 worden de beschermingsbeleidsregels voor polling ingesteld op AFDWINGEN en zullen de fouten voor gebruikers worden geactiveerd.
Neem contact op met je CSM als je hulp nodig hebt of vragen hebt.
In de sandbox-omgeving wordt het polling-beleid ingesteld om fouten te LOGGEN op 17 september 2025 en op AFDWINGEN op 25 september 2025.
|
Eerst gerapporteerd: augustus 2025 |
Verwijderd uit huidige lijst: feb 2026 |
|---|
Om FedRAMP CSP-vereisten te ondersteunen, schakelen we het IPv6-protocol in op onze Acrobat Sign for Government -omgeving:
- 2001:489a:3102:4::160/124 (IPv6)
- 2001:489a:3102:4::150/124 (IPv6)
|
Eerst gerapporteerd: september 2025 |
Verwijderd uit huidige lijst: feb 2026 |
|---|
De validatie van taalinstellingen is aangescherpt bij het maken van een overeenkomst via API. Als de landinstelling van een overeenkomst niet is toegestaan volgens het beleid van het account, wijst de API de aanvraag af met een duidelijke foutmelding. Dit vermindert onbedoelde taalverschillen en zorgt ervoor dat de ervaringen van ontvangers in lijn blijven met goedgekeurde instellingen.
Wie wordt hierdoor beïnvloed
- Accounts die de landinstelling van de overeenkomst instellen in API-aanvragen.
- Accounts die beschikbare landinstellingen beperken of wijzigingen in landinstellingen tijdens het verzenden niet toestaan.
Wat er is gewijzigd?
Wanneer de instelling DISPLAY_LOCALE_INFO_DURING_SEND is ingeschakeld (GLOBAL-niveau), handhaaft de API het volgende:
- De landinstelling van de overeenkomst moet zijn opgenomen in de AVAILABLE_LOCALES van de gebruiker.
- Als ALLOW_LOCALE_SELECTION_DURING_SEND false is, moet de landinstelling van de overeenkomst overeenkomen met de AGREEMENT_LOCALE van de gebruiker.
Bij overtredingen mislukt POST /agreements met: "Landinstelling is ongeldig of ontbreekt."
Veelvoorkomende fout en hoe deze op te lossen
Fout: "Landinstelling is ongeldig of ontbreekt."
- Controleer de landinstelling die in de API-aanvraag wordt gebruikt (bijvoorbeeld en_US).
- Bevestig dat de landinstelling voorkomt in AVAILABLE_LOCALES voor de oproepende gebruiker.
- Als ALLOW_LOCALE_SELECTION_DURING_SEND false is, zorg er dan voor dat de landinstelling van de aanvraag overeenkomt met AGREEMENT_LOCALE.
- Als flexibiliteit tussen regio's vereist is, schakel dan de selectie van landinstellingen tijdens het verzenden in (zie Vereiste actie).
Achterwaartse compatibiliteit
- Vóór deze wijziging konden sommige aanvragen met niet-overeenkomende landinstellingen slagen. Dergelijke aanvragen mislukken nu met een duidelijke foutmelding wanneer de validaties niet slagen.
- Geen wijzigingen in API-schema; validatiegedrag verandert alleen wanneer DISPLAY_LOCALE_INFO_DURING_SEND is ingeschakeld.
Vereiste actie
Beheerders en API-integrators moeten een van de volgende dingen doen:
- Stem de landinstelling in API-verzoeken af op AVAILABLE_LOCALES, en—als ALLOW_LOCALE_SELECTION_DURING_SEND false is—stem AGREEMENT_LOCALE exact af
- of -
- Sta selectie van landinstelling tijdens verzenden toe door het volgende in te stellen:
- ALLOW_LOCALE_SELECTION_DURING_SEND = true
- CAN_CHANGE_UI_LOCALE = true
|
Eerst gemeld: december 2025 |
Verwijderd uit huidige lijst: feb 2026 |
|---|
adobe acrobat sign zal het adobe acrobat sign SSL-certificaat roteren op 7 januari 2026.
Actie vereist
- Als je aangepaste integraties hebt met acrobat sign die gebruikmaken van de REST API's en als een van deze integraties de bestaande openbare sleutel heeft 'vastgezet', is geen verdere actie vereist.
- Als je SSL-certificeringen van Acrobat Sign gebruikt voor SSO, of als je het certificaat zelf vastpint (of andere methoden gebruikt), kun je de nieuwe SSL-certificeringen van Acrobat Sign vinden in de systeemvereisten van Adobe Acrobat Sign.
- Als uw SSO-configuratie meerdere openbare certificaten/ketens ondersteunt, kunt u de nieuwe certificaten nu toevoegen en de oude openbare certificaten/ketens na de overstap van januari uit uw configuratie verwijderen.
- Als je SSO geen ondersteuning biedt voor meerdere openbare certificaten/ketens, moet je je SSL-switch synchroniseren met acrobat sign op 7 januari 2026.
De nieuwe SSL-certificeringen worden Primaire op 7 januari 2026.
|
Eerst gerapporteerd: september 2024 - Bijgewerkt: april 2025 |
Actueel |
|---|
De Webhook 2.0-infrastructuur is uitgerold voor alle klanten en om die reden zijn meldingen aan ondertekenaars beëindigd. Daardoor biedt de parameter webhookNotificationApplicableUsers van de Webhook-payload geen bruikbare gegevens meer en wordt deze verwijderd uit alle Webhook-payloads.
De productieomgevingen worden bijgewerkt in de release van juni.
De productieomgevingen worden bijgewerkt in de release van juli 2025.
De verzendende gebruikers-ID en e-mail zijn te vinden met behulp van de parameters initiatingUserId en initiatingUserEmail in de meldingspayload.