Adobe Acrobat Sign brengt minimaal drie updates per jaar uit, gecategoriseerd als grote of kleine releases. Indien nodig kunnen er aanvullende kleine updates worden doorgevoerd om systeem- of klantproblemen op te lossen.

Grote releases brengen belangrijke updates, nieuwe functies en verdere verbeteringen.
Kleine releases richten zich op kleinere verbeteringen en aanpassingen van de gebruikerservaring. Deze vinden plaats tussen grote updates, meestal één tot twee keer per cyclus.

Om onderbrekingen te voorkomen zijn nieuwe functies standaard uitgeschakeld en moeten ze handmatig worden ingeschakeld door een account- of groepsbeheerder.

Voor klanten in de Health and Life-wetenschappen die behoefte hebben aan validatie van de naleving, werkt Acrobat Sign samen met een externe leverancier om een validatiepakket voor elke grote release te leveren met functies waarmee uw risico's worden geminimaliseerd.

Opmerking:

Deze pagina met Informatie voorafgaand aan de release wordt regelmatig bijgewerkt naarmate nieuwe informatie beschikbaar wordt, waardoor de inhoud vrij dynamisch is.

Hoewel de pagina is gelokaliseerd, kost het proces tijd. Hierdoor kunnen gelokaliseerde versies soms enigszins afwijken van de officiële Amerikaans-Engelse versie.

Raadpleeg de pagina voor Amerikaans-Engels voor de meest nauwkeurige en up-to-date informatie.

Het prereleaseschema en de opmerkingen staan hieronder vermeld.

Adobe Acrobat Sign volgt een gestructureerde planning voor het publiceren van aanvullende informatie en documentatie-updates:

8 weken voor de productierelease

De prereleasepagina bevat een samenvatting van verwachte functies en updates, meestal vier weken voor de Sandbox-lancering.
Functies die na dit tijdstip worden gewijzigd, worden vermeld in de sectie Errata.
Opgeloste problemen worden in dit stadium niet vermeld.

4 weken voor productierelease (Sandbox-lancering)

De prereleasepagina wordt bijgewerkt met gedetailleerde documentatie over nieuwe en bijgewerkte functies.
Indien nodig worden koppelingen naar documentatie voor ondersteuning van de prerelease toegevoegd. Deze zijn alleen beschikbaar in het Amerikaans-Engels.
De eerste sectie Opgeloste problemen wordt gepubliceerd, met doorlopende updates voor de volgende vier weken.

Dag van de lancering

De officiële aanvullende informatie wordt bijgewerkt met definitieve informatie over de functies, en met koppelingen naar de documentatie voor productieondersteuning.
De prereleasepagina wordt vernieuwd zodat de volgende releasecyclus wordt gemarkeerd.
De documentatie wordt gepubliceerd na verificatie van de release in het live-systeem, doorgaans na 19.00 uur Pacific Time, al kan dat bij complexe updates later zijn.
De definitieve lijst met opgeloste problemen wordt aan de aanvullende informatie in het Amerikaans-Engels toegevoegd. Gelokaliseerde versies worden later bijgewerkt.

Government Cloud-release

De Government Cloud-omgeving wordt doorgaans twee dagen tot enkele weken na de productierelease bijgewerkt, omdat bepaalde functies soms verder moeten worden geëvalueerd voordat ze worden geïmplementeerd.

Opmerking:

Sandbox-documentatie is ontworpen voor de productieomgeving. Koppelingen in de prereleasecontent verwijzen naar productie-URL's. Dit betekent dat deze koppelingen kunnen leiden naar oudere, bestaande documentatie of 404-resultaten als de doelpagina nieuw is en nog niet is gepubliceerd (bijvoorbeeld wanneer de koppeling verwijst naar een nieuwe functie in dezelfde release).

De nieuwe pagina's worden gepubliceerd zodra de release is gepubliceerd en de koppelingen worden correct doorgestuurd naar de productie-URL's.

Beschikbaarheid van Sandbox

Klanten die toegang hebben tot de Acrobat Sign Sandbox-omgeving hebben doorgaans vier weken vóór de lancering toegang tot de functionaliteit van de nieuwe release.

De sandboxomgeving moet alle procedures voor productiekwaliteitsborging doorlopen op hetzelfde kwaliteitsniveau als de gebruikelijke productieomgeving.
Adobe streeft naar een beschikbaarheid van 99,9% in de sandboxomgeving, maar klanten moeten er rekening mee houden dat de Adobe Unified SLA de sandbox formeel niet omvat.
De sandboxomgeving gebruikt dezelfde statuspagina en uitvalprocedures als de gebruikelijke productieomgeving.

Releases

Waarschuwing:

Dit artikel bevat prerelease-informatie. Releasedatums, functies en andere informatie kunnen zonder voorafgaande kennisgeving worden gewijzigd.

17 maart 2026 (Kleine release) v17.0.1

Adobe Acrobat Sign losmaken v17.0.1

Sandbox-implementatie: 17 februari 2026

Productie-implementatie: 17 maart 2026

GovCloud-implementatie: 19 maart 2026

Verbeterde functionaliteit

Kopie maken – Uitgebreide toegangspunten, sneller hergebruik van overeenkomsten.
Kopie maken is nu direct beschikbaar vanuit de filters In uitvoering en Wacht op jou op de pagina Beheren, evenals vanaf de bevestigingspagina na verzending. Deze extra toegangspunten maken het eenvoudiger om overeenkomsten opnieuw te gebruiken op meer punten in de verzendlevenscyclus, waardoor het minder nodig is om opnieuw te starten vanaf het begin.
Deze functie wordt beschikbaar in de Sandbox-omgeving op 20 februari 2026.

Opmerking: Met deze release worden de administratieve controles om deze functie uit te schakelen verwijderd uit het beheerdersmenu, waardoor Een kopie maken wordt vastgesteld als een standaard mogelijkheid die beschikbaar is voor alle in aanmerking komende gebruikers.
Beschikbare omgevingen: Sandbox, Commercial, Government | Beschikbare servicelagen: Acrobat Sign Solutions | Configuratie-omvang: account en groep; standaard ingeschakeld.

Controleer de bijgewerkte documentatie voor gebruikersacties >

REST API/Webhookupdates

De onderstaande updates worden voor openbaarmakingsdoeleinden gepresenteerd in de aanvullende prerelease-informatie. Volledige documentatie voor API- en Webhook-updates is te vinden in de: Acrobat Sign-documentatie voor ontwikkelaars wanneer de versie-update aan de productieservers wordt geleverd.

OEM 2.0 gepersonaliseerde e-mailweergave – Duidelijkere afzender- en ontvanger-identiteit in ingesloten ervaringen en juiste e-mailbezorging.
Voor OEM 2.0 partner die ingesloten workflows gebruiken, toont acrobat sign nu het gepersonaliseerde e-mailadres van een gebruiker in plaats van het partner-geregistreerde e-mailadres op belangrijke gebruikersinterface-oppervlakken en meldingen. Overeenkomsten, wachtrijen zoals 'Wachten op jou' en 'Controleren en ondertekenen' e-mails weerspiegelen consistent de gepersonaliseerde identiteit terwijl het geregistreerde e-mailadres intern behouden blijft voor authenticatie en rechten. Dit verbetert de duidelijkheid voor verzenders en ondertekenaars en voorkomt dat e-mails worden verzonden naar niet-bezorgbare geregistreerde adressen.

Beschikbare omgevingen: Sandbox, Commercial | Beschikbare servicelagen: Acrobat Sign Solutions | Configuratie-omvang: API - alleen OEM 2.0 partner

Webhook-bericht voor SMS-bezorgingsfouten – Real-time zichtbaarheid van mislukte SMS-verzendingen, geautomatiseerd herstel en pariteit met e-mailbounces.
Acrobat Sign zendt nu een nieuwe webhook-gebeurtenis uit, AGREEMENT_PHONE_BOUNCED, wanneer een overeenkomst verzonden via SMS niet kan worden bezorgd vanwege problemen zoals ongeldige telefoonnummers, afwijzing door provider of geblokkeerde lijnen. Dit stelt klanten in staat om SMS-bezorgingsfouten in real-time te detecteren en automatisch vervolgacties te activeren zoals het corrigeren van telefoonnummers, opnieuw proberen van bezorging of het openen van ondersteuningszaken, waardoor blinde vlekken worden weggenomen en vertragingen in mobiel-first ondertekeningsworkflows worden verminderd.

Beschikbare omgevingen: Sandbox, Commercial, Government | Beschikbare servicelagen: acrobat sign Solutions | Configuratie-omvang: API

Webhook-payloads – Toegevoegd conditioneel deelnemer extendedStatus veld voor dynamische deelname-updates, verbeterde zichtbaarheid van deelnemerstatus.
Webhook-meldingen bevatten nu een extendedStatus veld in elk deelnemerobject (memberInfos[]) wanneer de afzender een lopende overeenkomst wijzigt met behulp van dynamische deelname. Dit veld biedt aanvullende details over de levenscyclus van deelnemers terwijl het bestaande status veld ongewijzigd blijft voor achterwaartse compatibiliteit.

        {
          &quot;participantSets&quot;: [
            {
              &quot;id&quot;: &quot;&quot;,
              &quot;memberInfos&quot;: [
                {
                  &quot;company&quot;: &quot;TestCo&quot;,
                  &quot;email&quot;: &quot;signer2@someDomain.dom&quot;,
                  &quot;id&quot;: &quot;CBJCHBCAABAAJiZV9cH&quot;,
                  &quot;name&quot;: &quot;Signer Two&quot;,
                  &quot;status&quot;: &quot;ACTIVE&quot;,
                  &quot;extendedStatus&quot;: &quot;REMOVED&quot;
                }
              ],
              &quot;order&quot;: ,
              &quot;role&quot;: &quot;&quot;,
              &quot;status&quot;: &quot;&quot;
            }
          ]
        }

status waarden (ongewijzigd): ACTIVE, REPLACED.
extendedStatus waarden: ACTIVE, REPLACED, REMOVED, COMPLETED.

Beschikbare omgevingen: Sandbox, Commercial, Government | Beschikbare servicelagen: acrobat sign Solutions | Configuratie-omvang: API

Errata vrijgeven

Er zijn op dit moment geen items uit deze release verdwenen.

Opgeloste problemen

Probleem	Beschrijving
4543515	Samenvatting: Een webhook e-mail bounce-gebeurtenis kan ten onrechte worden gegenereerd voor een geldige ondertekenaar nadat de ondertekenaar succesvol heeft ondertekend en de overeenkomst doorgaat naar de volgende stap. Dit kan optreden wanneer een gemachtigde in dezelfde ondertekeningsgroep een ongeldig e-mailadres heeft en de verzender de oorspronkelijke gemachtigde vervangt. In deze gevallen kan het systeem ten onrechte de 'ondertekend namens...' bounce-gebeurtenis toewijzen aan de geldige ondertekenaar in plaats van aan de deelnemer wiens e-mail daadwerkelijk bounced.
4543515	Oplossing: De logica voor gebeurtenisattributie werd gecorrigeerd zodat e-mail bounce-gebeurtenissen alleen worden gekoppeld aan de deelnemer wiens e-mail daadwerkelijk bounced. Een bounce-gebeurtenis wordt niet langer gegenereerd voor een geldige ondertekenaar die al klaar is met ondertekenen, en webhook-meldingen geven nu de juiste deelnemer en e-mailadres weer.
4544548	Samenvatting: Integratiesleutels die zijn gemaakt via de web gebruikersinterface kunnen na tien jaar verlopen, ook al staat op de aanmaakpagina dat de sleutel 'permanente toegang' biedt. Wanneer een sleutel zijn levensduur van tien jaar bereikt, beginnen API-aanroepen een verlopen token-fout te retourneren, wat bestaande integraties onverwacht kan breken.
4544548	Oplossing: De messaging van de gebruikersinterface werd bijgewerkt om de bewoordingen 'permanente toegang' te verwijderen en de vervaldatum voor integratiesleutels duidelijk weer te geven. De bijgewerkte tekst stelt nu dat de sleutel toegang behoudt tot de vervaldatum of totdat deze handmatig wordt ingetrokken, wat transparantie biedt over de standaard levensduur van tien jaar.
4546301	Samenvatting: Webhook-gebeurtenisbezorging kan worden vertraagd met meerdere uren voor overeenkomsten met zeer grote document, zelfs wanneer het maken van overeenkomsten wordt voltooid en vroege verwerkingsstappen binnen minuten lijken te eindigen. Tijdens het vertragingsvenster kan de webhook-bezorgingsservice herhaaldelijk DOCUMENT_NOT_AVAILABLE-reacties ontvangen bij het proberen om overeenkomstdocument op te halen, en de webhook-gebeurtenis wordt mogelijk niet bezorgd totdat de service stopt met opnieuw proberen of de document beschikbaar worden.
4546301	Oplossing: Beschikbaarheidsafhandeling van document werd gecorrigeerd zodat grote overeenkomsten betrouwbaar overgaan naar een staat waarin document opvraagbaar zijn zonder uitgebreide DOCUMENT_NOT_AVAILABLE-reacties. Als gevolg hiervan worden webhook-gebeurtenissen bezorgd zonder vertragingen van meerdere uren veroorzaakt door herhaalde pogingen om document op te halen die niet beschikbaar zijn.
4547823	Samenvatting: Het privébericht van een ontvanger wordt mogelijk niet weergegeven voor sommige ondertekenaars wanneer een overeenkomst wordt gemaakt in de authoring-staat via de API en vervolgens wordt bewerkt vanuit de beheerervaring. In dit scenario kan de gebruikersinterface de waarde van het privébericht tonen als 'Geen' of leeg, ook al bevat de overeenkomstgegevens de juiste privéberichtwaarde. Dit gedrag verschijnt in gedeelde-account-scenario's waarbij een gebruiker overschakelt naar het account van een andere gebruiker om het concept te bewerken, en het kan alleen specifieke ontvangers beïnvloeden terwijl anderen correct worden weergegeven.
4547823	Oplossing: Een controle werd toegevoegd om de primaire deelcontext op te halen en het privébericht te retourneren voor geautoriseerde gedeelde gebruikers. Als gevolg hiervan wordt de waarde van het privébericht nu correct weergegeven bij het bekijken of verzenden van een API-gemaakt concept vanuit de authoring-flow.
4548274	Samenvatting: De wijzigingsdatum voor bibliotheeksjablonen wordt mogelijk niet bijgewerkt nadat een sjabloon is bewerkt en opgeslagen in de nieuwe sjabloonervaring. Gebruikers kunnen nieuw toegevoegde of bijgewerkte velden op de sjabloon zien, maar de wijzigingsdatum blijft ongewijzigd in de beheer-gebruikersinterface en in administratieve weergaven, waardoor het lijkt alsof de sjabloon niet recent is gewijzigd. Dit gebeurt omdat de nieuwe ervaring formuliervelden bijwerkt via een pad dat niet ook de gewijzigde tijdstempel van de sjabloon bijwerkt.
4548274	Oplossing: Het gedrag voor het bijwerken van de gewijzigde datum werd afgestemd op de nieuwe sjabloon-ervaring en de gerelateerde API-bewerkingen.Het codepad dat wijzigingen in sjabloonvelden opslaat, werkt nu ook de gewijzigde datum van de sjabloon bij zodat deze de werkelijke tijd van de meest recente wijziging weergeeft.
4548564	Samenvatting: Handtekeningen en formuliervelden kunnen onzichtbaar lijken in het ondertekende pdf-bestand wanneer ze worden geplaatst over reeds bestaande stempel-notities in het brondocument.In getroffen sjablonen overlappen de stempel-notities de interactieve velden tijdens het verwerken of maken ze deze onzichtbaar, waardoor voltooide handtekeningen en andere velden verborgen zijn in het definitieve ondertekende document.
4548564	Oplossing: De verwerking van stempel-notities werd bijgewerkt om reeds bestaande stempel-notities veilig te verwerken en af te vlakken zodat ze formuliervelden of handtekeningen niet langer verbergen.Velden die over gestempelde gebieden zijn geplaatst, blijven nu zichtbaar tijdens het ondertekenen en in het volledig uitgevoerde pdf-bestand.
4549103	Samenvatting: Een e-mail bounce-gebeurtenis kan opnieuw worden geregistreerd voor een eerder onjuiste ontvanger nadat de afzender die ontvanger vervangt door een geldig e-mailadres.In sommige gevallen kan het auditspoor een tweede bounce-gebeurtenis voor de oude e-mail tonen, en de overeenkomststatus kan 'e-mail bounced' weergeven ondanks dat de nieuwe ontvanger de overeenkomst succesvol ontvangt, bekijkt of ondertekent.Dit gedrag kan de indruk wekken dat de overeenkomst nog steeds gericht is op zowel het oude als het nieuwe e-mailadres.
4549103	Oplossing: De workflow voor het vervangen van ondertekenaars werd bijgewerkt om te voorkomen dat aanvullende bericht-e-mails worden verzonden naar een vervangen ontvanger wiens e-mail al is gebounced.Het systeem controleert nu op eerdere bounce-historie voordat het vervangingsgerelateerde berichten verzendt, waardoor wordt gegarandeerd dat er geen nieuwe bounce-gebeurtenissen worden gegenereerd voor het oude e-mailadres na vervanging.
4549306	Samenvatting: Gebruikers wiens e-mailadressen bepaalde speciale tekens bevatten (bijvoorbeeld een apostrof) kunnen mogelijk niet inloggen vanaf de generieke adobesign.com of echosign.com openbare login-pagina's.Na het invoeren van het e-mailadres en het klikken in het wachtwoordveld, kan de pagina opnieuw laden en het e-mailveld wissen in plaats van de gebruiker door te sturen naar de juiste shard of SSO login-pagina.Dit voorkomt dat getroffen gebruikers de authenticatie voltooien en blokkeert integraties die afhankelijk zijn van het openbare login-eindpunt.
4549306	Oplossing: De login shard-resolutielogica werd gecorrigeerd om e-mailadressen met speciale tekens correct te verwerken en te decoderen voordat de inter-shard doorstuur-URL wordt samengesteld.Gebruikers met getroffen e-mailformaten worden nu correct doorgestuurd naar hun aangewezen shard en SSO login-pagina zonder dat het e-mailveld wordt gewist.
4549331	Samenvatting: Handtekeningen en andere formuliervelden kunnen ontbreken of onzichtbaar lijken in het ondertekende pdf-bestand wanneer bepaalde documentverwerkingsfuncties zijn ingeschakeld en het bron-pdf-bestand ongeldige paginaboxcoördinaten bevat (bijvoorbeeld onjuiste CropBox- of MediaBox-waarden).In dit scenario kunnen velden die afhankelijk zijn van paginacoördinaten buiten het zichtbare paginagebied worden weergegeven, waardoor voltooide handtekeningen ontbreken lijken ondanks dat het ondertekenen succesvol wordt voltooid.
4549331	Oplossing: De verwerking van pdf-paginaboxen werd gecorrigeerd om ongeldige CropBox- en MediaBox-waarden veilig te normaliseren tijdens documentverwerking.Als gevolg hiervan wordt de plaatsing van handtekeningen en formuliervelden nu afgestemd op het zichtbare paginagebied, en tonen ondertekende pdf-bestanden handtekeningen zoals verwacht.
4550367	Samenvatting: Het maken van een webformulier kan mislukken met een generieke 'Server fout' na het selecteren van Voorvertoning en velden toevoegen wanneer de standaard ondertekenaarsauthenticatie van de afzendergroep is ingesteld op Telefoon en het account geen beschikbare telefoonauthenticatiequota heeft, zelfs als de webformulier-ondertekenaarsauthenticatie is ingesteld op een niet-telefoonmethode (bijvoorbeeld Adobe Sign).Als gevolg hiervan kunnen alle gebruikers in het getroffen account worden geblokkeerd bij het maken van webformulieren voor alle documenten.
4550367	Oplossing: Het maken van webformulieren evalueert nu alleen quota voor de authenticatiemethode die daadwerkelijk is geconfigureerd voor de webformulier-ondertekenaar, en past niet langer telefoonauthenticatiequotacontroles toe gebaseerd alleen op de standaard authenticatie-instelling van de groep.Dit voorkomt valse quota-uitputtingsfouten en maakt het mogelijk dat webformulieren normaal worden gemaakt.
4551011	Samenvatting: Wanneer een afzender bepaalde gescande pdf's uploadt, handtekeningvelden toevoegt en de overeenkomst verstuurt, kan de ondertekende pdf geen zichtbare handtekeningen weergeven nadat het ondertekenen is voltooid. Dit gedrag kan optreden wanneer de geüploade pdf ongeldige paginagrens-metadata bevat (MediaBox- en CropBox-coördinaten lijken omgekeerd), wat ertoe kan leiden dat handtekening- en andere veldweergavelagen buiten het zichtbare paginagebied worden weergegeven.
4551011	Oplossing: De verwerking van pdf-paginagrenzen is bijgewerkt om pdf's met ongeldige of omgekeerde MediaBox- en CropBox-coördinaatwaarden correct te verwerken, zodat handtekening- en formulierveldweergave-content binnen het zichtbare paginagebied wordt weergegeven en zichtbaar blijft in de uiteindelijke ondertekende pdf.
4551427	Samenvatting: Sommige ontvangers die al Primaire, correct ingerichte accounts hebben, ontvangen overeenkomsten als 'pseudo-gebruiker'-ontvangers, waardoor de overeenkomst niet verschijnt in hun normale beheren-weergave. Dit gebeurt wanneer e-mailadressen van ontvangers voorloop- of volgspaties bevatten, wat voorkomt dat het systeem de e-mail koppelt aan de bestaande gebruiker en zorgt voor het aanmaken van een pseudo-gebruikersrecord.
4551427	Oplossing: E-mailparsing en gebruikersopzoeken zijn bijgewerkt om e-mailadressen van ontvangers te normaliseren (voorloop- en volgspaties verwijderen) voordat ze worden gekoppeld aan bestaande gebruikers. Als gevolg hiervan worden overeenkomsten die zijn gericht aan bestaande gebruikers gekoppeld aan het geregistreerde account in plaats van het aanmaken van een pseudo-gebruikerontvanger, zelfs als de e-mail is ingevoerd met spaties (in API-payloads en workflow-ontvangerslijsten).
4553198	Samenvatting: Wanneer een overeenkomst ten minste één ontvanger bevat die is geconfigureerd voor sms-bezorging en ten minste één ontvanger die is geconfigureerd voor alleen e-mailbezorging, wordt er geen sms-annuleringsbericht verzonden naar de sms-ontvanger wanneer de overeenkomst via de API wordt geannuleerd. De overeenkomst wordt succesvol geannuleerd en e-mailberichten worden bezorgd, maar sms-ontvangers ontvangen geen annuleringsbericht.
4553198	Oplossing: De annuleringsworkflow is gecorrigeerd om ervoor te zorgen dat sms-annuleringsberichten worden verzonden naar alle ontvangers die zijn geconfigureerd voor sms-bezorging wanneer een overeenkomst wordt geannuleerd, ongeacht de bezorgingsmethoden van andere ontvangers.
4554463	Samenvatting: Wanneer overeenkomsten gekloonde keuzerondjes bevatten die dezelfde veldnaam delen over gecombineerde documenten, blijft slechts één instantie van de geselecteerde optie geselecteerd in de uiteindelijke ondertekende pdf. Hoewel de velden visueel verschijnen als selectievakjes, zijn ze geïmplementeerd als keuzerondjes. Na ondertekening wordt de geselecteerde Waarde niet consistent doorgegeven aan alle gekloonde instanties, wat zorgt voor onjuiste of onvolledige toewijzing van de verwachte selectie.
4554463	Oplossing: De logica voor formulierveldverwerking is gecorrigeerd zodat gekloonde keuzerondjes de geselecteerde exportwaarde opslaan en doorgeven in plaats van een interne Index-waarde. Dit zorgt ervoor dat alle gekloonde instanties van hetzelfde keuzerondje-veld de juiste selectie weergeven in de ondertekende pdf.
4554593	Samenvatting: Sommige partner-integraties die de verouderd OAuth-eindpunten gebruiken om toegangstokens te vernieuwen, begonnen te falen met HTTP 401-fouten. De service wees token-vernieuwingsverzoeken af met een fout die aangaf dat de app niet is toegestaan om de verouderd OAuth-eindpunten te gebruiken en in plaats daarvan de OAuth v2-eindpunten moet gebruiken. Dit blokkeerde klanten om Acrobat Sign te authenticeren via partner-apps, zelfs voor integraties die eerder werkten.
4554593	Oplossing: De authenticatieservice is gecorrigeerd zodat partner-apps die zijn geconfigureerd om de verouderd OAuth-flow te gebruiken weer succesvol tokens kunnen vernieuwen, in plaats van onjuist te worden gedwongen naar de OAuth v2-eindpunten.
4554614	Samenvatting: Wanneer een ondertekenaar de moderne eSign-ervaring gebruikt voor een overeenkomst die ondertekenaarauthenticatie vereist en is geconfigureerd om acceptatie van gebruiksvoorwaarden vóór ondertekening te vereisen, activeert het klikken op Klik om te ondertekenen een doorsturen van vijf seconden naar de klassieke ondertekeningservaring. Het doorstuur-bericht waarschuwt dat handtekeningen en initialen die zijn ingevoerd in moderne ondertekening worden gewist, waardoor de ondertekenaar ze opnieuw moet invoeren en effectief twee keer moet ondertekenen.
4554614	Oplossing: De token-vernieuwingsflow voor ondertekening is gecorrigeerd zodat wanneer de ondertekenaar de gebruiksvoorwaarden accepteert vóór ondertekening, het opnieuw uitgegeven ondertekeningstoken de authenticatiedetails van de ondertekenaar behoudt. Dit voorkomt dat de laatste ondertekeningsstap faalt bij authenticatie en elimineert de gedwongen terugval van moderne ondertekening naar de klassieke ervaring.
4555656	Samenvatting: Onder specifieke timingomstandigheden kan een overgangswijziging van een overeenkomst lijken te slagen maar wijzigt de status van de overeenkomst niet daadwerkelijk. Wanneer een webhook-bericht wordt ontvangen voordat backend-verwerking is voltooid, kunnen daaropvolgende API-aanroepen verouderde overeenkomst-statusgegevens gebruiken. In dit venster retourneren bepaalde statusovergang-methoden HTTP 200 OK even al bevindt de overeenkomst zich niet in een geldige status voor de gevraagde overgang.Hierdoor kunnen geautomatiseerde workflows aannemen dat de overgang is geslaagd terwijl de overeenkomst in de oorspronkelijke status blijft.
4555656	Oplossing: De logica voor statusovergangen van overeenkomsten is bijgewerkt om strikte validatie af te dwingen voordat een overgang wordt toegepast.Als de overeenkomst zich niet in een geldige status bevindt, retourneert de API nu een duidelijke fout-reactie in plaats van stilletjes succes te retourneren.Dit zorgt ervoor dat ongeldige overgangen expliciet worden afgewezen, stelt aanroepende systemen in staat om op de juiste manier opnieuw te proberen en voorkomt dat overeenkomsten in een onbedoelde status blijven zonder Zichtbaarheid.