Niet alle functies/wijzigingen zijn gegarandeerd ingeschakeld op de datum van de release. Verwijs altijd naar de Amerikaanse Engelstalige versie van de pagina als de meest actuele en nauwkeurige versie.

Adobe Acrobat Sign release v17.0.1

Productie-implementatie: 17 maart 2026

GovCloud-implementatie: 19 maart 2026

Verbeterde functionaliteit

Kopie maken – Uitgebreide toegangspunten, sneller hergebruik van overeenkomsten.
Een kopie maken is nu direct beschikbaar via de filters In behandeling en In afwachting van u op de pagina Beheren, evenals op de bevestigingspagina na verzending. Deze extra toegangspunten maken het gemakkelijker om overeenkomsten op meer punten in de verzendcyclus opnieuw te gebruiken, waardoor het minder vaak nodig is om helemaal van voren af aan te beginnen.
Opmerking: Met deze release worden de beheerbesturingselementen om deze functie uit te schakelen verwijderd uit het beheerdersmenu, waardoor Kopie maken een standaardfunctie wordt die beschikbaar is voor alle in aanmerking komende gebruikers.

Beschikbare omgevingen: Sandbox, Commercial, Government | Beschikbare serviceniveaus: Acrobat Sign Solutions | Configuratiebereik: Account en groep; standaard ingeschakeld.

De bijgewerkte documentatie over gebruikersacties bekijken >

Wijzigingen in gebruikerservaring

Zichtbaarheid van de vervaldatums van integratiesleutels – vervaldatums worden nu getoond op het tabblad Toegangstokens
Het tabblad Toegangstokens, in het menu Persoonlijke voorkeuren, toont de vervaldatum voor elke integratiesleutel. Hierdoor krijgen gebruikers en beheerders een duidelijker beeld van de geldigheidsduur en vervangingstermijnen van sleutels, waardoor het gemakkelijker wordt om bestaande sleutels in de gaten te houden en onverwachte onderbrekingen te voorkomen, als een sleutel het einde van zijn geldigheidsduur van 10 jaar heeft bereikt.

Beschikbare omgevingen: Sandbox, Commercial, Government | Beschikbare serviceniveaus:Acrobat Sign Solutions | Configuratiebereik: API

REST API/Webhookupdates

API- en webhook-updates voor deze release zijn te vinden in de Acrobat Sign API-documentatie.

OEM 2.0-gepersonaliseerde e-mailweergave – duidelijkere weergave van identiteit van afzender en ontvanger in alle ingesloten ervaringen en correcte bezorging van e-mails.
Voor OEM 2.0-partners die ingesloten workflows gebruiken, kan Acrobat Sign nu op belangrijke onderdelen van de gebruikersinterface en in meldingen het gepersonaliseerde e-mailadres van een gebruiker weergeven in plaats van het door de partner geregistreerde e-mailadres. In overeenkomsten, wachtrijen zoals 'In afwachting van u' en e-mails in het kader van 'Controleren en ondertekenen' wordt de gepersonaliseerde identiteit consequent weergegeven, terwijl het geregistreerde e-mailadres intern wordt bewaard voor verificatie en rechten. Dit zorgt voor meer duidelijkheid bij afzenders en ondertekenaars en voorkomt dat e-mails naar geregistreerde adressen worden verzonden die geen e-mails kunnen ontvangen.

Beschikbare omgevingen: Sandbox, Commercial | Beschikbare serviceniveaus: Acrobat Sign Solutions | Configuratiebereik: API - OEM 2.0-partners; alleen op aanvraag

Webhookmelding bij mislukte bezorgingen van sms'en – realtime zichtbaarheid van mislukte sms-verzendingen, geautomatiseerde oplossing en vergelijkbaarheid met e-mails met bounce.
Acrobat Sign genereert nu een nieuwe webhookgebeurtenis, AGREEMENT_PHONE_BOUNCED, wanneer een via sms verzonden overeenkomst niet kan worden bezorgd vanwege problemen zoals ongeldige telefoonnummers, weigering door de provider of geblokkeerde lijnen. Hierdoor kunnen klanten fouten in de bezorging van sms'en vrijwel in realtime detecteren en automatisch vervolgacties in gang zetten, zoals het corrigeren van telefoonnummers, het opnieuw verzenden van sms'en of het openen van supporttickets, waardoor blinde vlekken worden weggenomen en vertragingen in op mobiel gerichte ondertekeningsworflows worden verminderd.

Beschikbare omgevingen: Sandbox, Commercial, Government | Beschikbare serviceniveaus: Acrobat Sign Solutions | Configuratiebereik: API

Webhook-payloads – het voorwaardelijke veld extendedStatus voor deelnemers is toegevoegd voor dynamische updates over de deelname, waardoor de status van deelnemers beter zichtbaar wordt.
Webhookmeldingen bevatten nu een veld extendedStatus 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 statusveld 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;
            }
          ]
        }

waarden voor status (ongewijzigd): ACTIEF, VERVANGEN.
Waarden voor extendedStatus: ACTIEF, VERVANGEN, VERWIJDERD, VOLTOOID.

Beschikbare omgevingen:: Sandbox, Commercial, Government | Beschikbare serviceniveaus: Acrobat Sign Solutions | Configuratiebereik: API

Opgeloste problemen

Probleem	Beschrijving
4543515	Samenvatting: Er kan ten onrechte een webhook over een bounce-gebeurtenis voor een geldige ondertekenaar worden gegenereerd, nadat deze de overeenkomst met succes heeft ondertekend en de overeenkomst naar de volgende stap gaat. Dit kan voorkomen wanneer een gedelegeerde in dezelfde ondertekeningsgroep een ongeldig e-mailadres heeft en de afzender de oorspronkelijke delegeerder vervangt. In deze gevallen kan het systeem de bounce-gebeurtenis 'ondertekend namens…' ten onrechte toeschrijven aan de geldige ondertekenaar in plaats van aan de deelnemer wiens e-mail daadwerkelijk is teruggestuurd.
4543515	Oplossing: De logica voor het toewijzen van gebeurtenissen is aangepast, zodat bounce-gebeurtenissen voor e-mails alleen worden gekoppeld aan de deelnemer wiens e-mail daadwerkelijk wordt teruggestuurd. Er wordt geen bounce-gebeurtenis meer gegenereerd voor een geldige ondertekenaar die het ondertekenen al heeft voltooid, en in webhookmeldingen worden nu de juiste deelnemer en het juiste e-mailadres weergegeven.
4544548	Samenvatting: Integratiesleutels die via de webinterface zijn gemaakt, kunnen na 10 jaar vervallen, ook al staat op de maakpagina vermeld dat de sleutel 'permanente toegang' biedt. Als een sleutel het einde van zijn geldigheidsduur van 10 jaar bereikt, geven API-aanroepen een foutmelding weer dat het token is vervallen, waardoor bestaande integraties onverwacht kunnen worden onderbroken.
4544548	Oplossing: De tekst in de gebruikersinterface is bijgewerkt om de bewoording 'permanente toegang' te verwijderen en de vervaldatum voor integratiesleutels duidelijk weer te geven. In de bijgewerkte tekst staat nu dat de sleutel toegang blijft verlenen tot de vervaldatum of totdat deze handmatig wordt ingetrokken, waardoor duidelijkheid wordt geboden over de standaardgeldigheidsduur van 10 jaar.
4546301	Samenvatting: De levering van webhookgebeurtenissen kan bij overeenkomsten met zeer grote documenten tot meerdere uren worden vertraagd, zelfs als het opstellen van de overeenkomst is voltooid en de eerste verwerkingsstappen binnen enkele minuten lijken te zijn afgerond. Tijdens de vertragingsperiode kan de webhook-bezorgservice herhaaldelijk DOCUMENT_NOT_AVAILABLE-reacties ontvangen bij pogingen om overeenkomstdocumenten op te halen en wordt de webhookgebeurtenis mogelijk pas bezorgd als de service stopt met opnieuw proberen of als de documenten beschikbaar komen.
4546301	Oplossing: De afhandeling van de beschikbaarheid van documenten is aangepast, zodat grote overeenkomsten betrouwbaar worden omgezet naar een status waarin documenten zonder uitgebreide DOCUMENT_NOT_AVAILABLE-reacties kunnen worden opgehaald. Hierdoor worden webhookgebeurtenissen zonder vertragingen van meerdere uren verzonden die worden veroorzaakt door herhaalde pogingen om documenten op te halen die niet beschikbaar zijn.
4547823	Samenvatting: Een privébericht van een ontvanger wordt mogelijk voor sommige ondertekenaars niet weergegeven, wanneer een overeenkomst via de API in de status Authoring wordt gemaakt en vervolgens vanuit de beheerervaring wordt bewerkt. In dit scenario kan de gebruikersinterface de waarde van het privébericht weergeven als 'Geen' of leeg, ook al bevatten de overeenkomstgegevens de juiste waarde voor het privébericht. Dit gedrag doet zich voor in situaties waarin meerdere gebruikers één account delen en een gebruiker overschakelt naar het account van een andere gebruiker om het concept te bewerken. Het kan zijn dat dit alleen gevolgen heeft voor bepaalde ontvangers, terwijl het bij anderen correct wordt weergegeven.
4547823	Oplossing: Er is een controle toegevoegd om de actieve deelcontext op te halen en het privébericht te retourneren voor geautoriseerde gebruikers van het gedeelde account. Hierdoor wordt de waarde van het privébericht nu correct weergegeven bij het bekijken of verzenden van een via de API gemaakt concept vanuit de authoring-workflow.
4548274	Samenvatting: De wijzigingsdatum van bibliotheeksjablonen wordt mogelijk niet bijgewerkt nadat een sjabloon in de nieuwe sjabloonervaring is bewerkt en opgeslagen. Gebruikers zien mogelijk nieuw toegevoegde of bijgewerkte velden in het sjabloon, maar de wijzigingsdatum blijft ongewijzigd in de beheerinterface en in de beheerweergaven, waardoor het lijkt alsof het sjabloon niet recent is gewijzigd. Dit gebeurt omdat de nieuwe ervaring formuliervelden via een pad bijwerkt dat ook niet de gewijzigde tijdstempel van het sjabloon bijwerkt.
4548274	Oplossing: Het gedrag voor het bijwerken van de wijzigingsdatum is in de nieuwe sjabloonervaring en de gerelateerde API-bewerkingen op elkaar afgestemd. Het codepad dat wijzigingen in sjabloonvelden opslaat, werkt nu ook de wijzigingsdatum van het sjabloon bij zodat deze de werkelijke tijd van de meest recente wijziging weergeeft.
4548564	Samenvatting: Handtekeningen en formuliervelden kunnen onzichtbaar lijken in de ondertekende PDF wanneer ze worden geplaatst over reeds bestaande stempelnotities in het brondocument. In getroffen sjablonen overlappen of verduisteren de stempelnotities de interactieve velden tijdens de verwerking, waardoor voltooide handtekeningen en andere velden verborgen worden in het definitieve ondertekende document.
4548564	Oplossing: De afhandeling van stempelnotities is bijgewerkt om reeds bestaande stempelnotities veilig te verwerken en af te vlakken zodat ze formuliervelden of handtekeningen niet langer verduisteren. Velden die over gestempelde gebieden zijn geplaatst, blijven nu zichtbaar tijdens het ondertekenen en in de volledig uitgevoerde PDF.
4549103	Samenvatting: Een e-mailterugkaatsevenement kan opnieuw worden geregistreerd voor een eerder onjuiste ontvanger nadat de afzender die ontvanger heeft vervangen door een geldig e-mailadres. In sommige gevallen kan de audittrail een tweede bounce-gebeurtenis voor de oude e-mail weergeven en kan de status van de overeenkomst 'e-mail teruggestuurd' aangeven, ook al heeft de nieuwe ontvanger de overeenkomst ontvangen, bekeken of ondertekend. 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 is bijgewerkt om te voorkomen dat aanvullende berichtmails worden verzonden naar een vervangen ontvanger wiens e-mail al is teruggekaatst. Het systeem controleert nu op de eerdere bounce-geschiedenis voordat vervangingsgerelateerde meldingen worden verzonden, om te voorkomen dat er na vervanging nieuwe bounce-gebeurtenissen voor het oude e-mailadres worden gegenereerd.
4549306	Samenvatting: Gebruikers van wie het e-mailadres bepaalde speciale tekens bevat (bijvoorbeeld een apostrof) kunnen mogelijk niet inloggen vanaf de algemene adobesign.com of echosign.com openbare inlogpagina'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-inlogpagina. Dit voorkomt dat getroffen gebruikers de authenticatie kunnen voltooien en blokkeert integraties die afhankelijk zijn van het openbare login-eindpunt.
4549306	Oplossing: De login shard-resolutielogica is gecorrigeerd om e-mailadressen met speciale tekens correct te verwerken en te decoderen voordat de inter-shard doorverwijzings-URL wordt samengesteld. Gebruikers met getroffen e-mailnotaties worden nu correct doorgestuurd naar hun aangewezen shard en SSO-inlogpagina zonder dat het e-mailveld wordt gewist.
4549331	Samenvatting: Handtekeningen en andere formuliervelden kunnen ontbreken of onzichtbaar lijken in de ondertekende PDF wanneer bepaalde documentverwerkingsfuncties zijn ingeschakeld en de bron-PDF ongeldige paginaboxcoördinaten bevat (bijvoorbeeld onjuiste CropBox- of MediaBox-waarden). In deze situatie kunnen velden die van paginacoördinaten afhankelijk zijn buiten het zichtbare paginagebied worden weergegeven, waardoor het lijkt alsof geplaatste handtekeningen ontbreken, ook al is het ondertekenen voltooid.
4549331	Oplossing: PDF-paginaboxverwerking is gecorrigeerd om ongeldige CropBox- en MediaBox-waarden veilig te normaliseren tijdens documentverwerking. Hierdoor wordt de plaatsing van handtekening- en formuliervelden nu uitgelijnd tot het zichtbare paginagebied en worden in ondertekende PDF's handtekeningen zoals verwacht weergegeven.
4550367	Samenvatting: Het maken van een webformulier kan mislukken met een algemene 'serverfout' na het selecteren van velden voor Voorbeeld en Toevoegen, wanneer de standaardverificatiemethode voor ondertekenaars van de afzendergroep is ingesteld op Telefoon en het account geen beschikbare limiet voor telefoonverificatie heeft, zelfs als de verificatiemethode voor ondertekenaars van het webformulier is ingesteld op een andere methode (bijvoorbeeld Adobe Sign). Hierdoor 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 limieten voor de verificatiemethode die daadwerkelijk is geconfigureerd voor de ondertekenaar van het webformulier. Er wordt geen limiet voor telefoonverificatie meer toegepast die alleen is gebaseerd op de standaardverificatie-instelling van de groep. Dit voorkomt fouten waarbij onterecht wordt aangegeven dat de limiet is bereikt en maakt het mogelijk om webformulieren op de normale manier te maken.
4551011	Samenvatting: Wanneer een afzender bepaalde gescande PDF's uploadt, handtekeningvelden toevoegt en de overeenkomst verzendt, worden mogelijk geen zichtbare handtekeningen in de ondertekende PDF weergegeven nadat het ondertekenen is voltooid. Dit gedrag kan optreden wanneer de geüploade PDF ongeldige metadata over paginagrenzen bevat (MediaBox- en CropBox-coördinaten zijn omgekeerd weergegeven), waardoor handtekeningen en andere veldweergavelagen buiten het zichtbare paginagebied kunnen 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 handtekeningen en de inhoud van formuliervelden binnen het zichtbare paginagebied worden weergegeven en zichtbaar blijven in de definitieve ondertekende PDF.
4551427	Samenvatting: Sommige ontvangers die al een actieve, correct ingerichte account hebben, ontvangen overeenkomsten echter als 'pseudogebruiker', waardoor de overeenkomst niet in hun normale Beheren-weergave verschijnt. Dit gebeurt wanneer het e-mailadres van de ontvanger een spatie aan het begin of eind bevat, waardoor het systeem het e-mailadres niet aan een bestaande gebruiker kan koppelen en er een record voor een pseudogebruiker wordt gemaakt.
4551427	Oplossing: Het parseren van e-mailadressen en het opzoeken van gebruikers zijn bijgewerkt om e-mailadressen van ontvangers te normaliseren (door spaties aan het begin en einde te verwijderen) voordat ze aan bestaande gebruikers worden gekoppeld. Hierdoor worden aan bestaande gebruikers gerichte overeenkomsten toegewezen aan het geregistreerde account, in plaats van dat er een pseudogebruiker als ontvanger wordt gemaakt, zelfs als het e-mailadres met spaties is ingevoerd (in API-payloads en lijsten met ontvangers voor de workflow).
4553198	Samenvatting: Wanneer een overeenkomst ten minste één ontvanger bevat die voor de bezorging van sms'en is geconfigureerd en ten minste één ontvanger bevat die uitsluitend voor de bezorging van e-mails is geconfigureerd, wordt er bij het annuleren van de overeenkomst via de API geen sms met een melding over de annulering naar de sms-ontvanger verzonden. 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 in alle samengevoegde documenten dezelfde veldnaam hebben, blijft slechts één instantie van de geselecteerde optie geselecteerd in de definitieve ondertekende PDF. Hoewel de velden visueel verschijnen als selectievakjes, zijn ze geïmplementeerd als keuzerondjes. Na het ondertekenen 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 het verwerken van formuliervelden is gecorrigeerd zodat gekloonde keuzerondjes de geselecteerde exportwaarde opslaan en doorgeven in plaats van een interne indexwaarde. 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 verouderde OAuth-eindpunten gebruiken om toegangstokens te vernieuwen, begonnen te falen met HTTP 401-fouten. De service heeft verzoeken om het tokens te vernieuwen afgewezen met een foutmelding waarin staat dat de applicatie geen gebruik mag maken van de verouderde OAuth-eindpunten, maar in plaats daarvan de OAuth v2-eindpunten moet gebruiken. Hierdoor konden klanten zich niet meer via partnerapplicaties bij Acrobat Sign aanmelden, zelfs niet bij integraties die voorheen wel werkten.
4554593	Oplossing: De verificatieservice is gecorrigeerd zodat partnerapplicaties die zijn geconfigureerd om de verouderde OAuth-workflow te gebruiken, weer tokens kunnen vernieuwen, in plaats van ten onrechte de OAuth v2-eindpunten te moeten gebruiken.
4554614	Samenvatting: Wanneer een ondertekenaar de moderne eSign-ervaring gebruikt voor een overeenkomst waarvoor verificatie van de ondertekenaar vereist is en die zo is geconfigureerd dat de gebruiksvoorwaarden vóór het ondertekenen moeten worden geaccepteerd, leidt het klikken op 'Klikken om te ondertekenen' tot een omleiding van 5 seconden naar de klassieke ondertekeningservaring. Het omleidingsbericht waarschuwt dat handtekeningen en initialen die in de moderne ondertekeningservaring zijn ingevoerd, worden gewist waardoor de ondertekenaar ze opnieuw moet invoeren en dus twee keer moet ondertekenen.
4554614	Oplossing: De workflow voor het vernieuwen van ondertekeningstokens is gecorrigeerd zodat wanneer de ondertekenaar de gebruiksvoorwaarden accepteert voor ondertekening, het opnieuw uitgegeven ondertekeningtoken de verificatiegegevens van de ondertekenaar behoudt. Dit voorkomt dat de verificatie mislukt bij de laatste ondertekeningsstap en zorgt ervoor dat er niet gedwongen wordt geschakeld van de moderne ondertekeningservaring naar de klassieke ervaring.
4555656	Samenvatting: Onder bepaalde timingomstandigheden kan een transitie van de overeenkomststatus geslaagd lijken, maar verandert de overeenkomststatus in werkelijkheid niet. Wanneer een webhook-bericht wordt ontvangen voordat backend-verwerking is voltooid, kunnen daaropvolgende API-aanroepen verouderde overeenkomststatusgegevens gebruiken. In dit tijdvenster retourneren bepaalde statusovergangsmethoden HTTP 200 OK, ook al is de overeenkomst niet in een geldige status voor de gevraagde overgang. Als gevolg hiervan kunnen automatiseringsworkflows aannemen dat de overgang is geslaagd terwijl de overeenkomst in de oorspronkelijke status blijft.
4555656	Oplossing: De logica voor de overeenkomststatustransities is bijgewerkt om strikte validatie af te dwingen, voordat een transitie wordt toegepast. Als de overeenkomst niet een geldige status had, retourneert de API nu een duidelijke foutmelding in plaats van stilzwijgend succes te melden. Dit zorgt ervoor dat ongeldige transities expliciet worden afgewezen, stelt aanroepende systemen in staat om op de juiste manier opnieuw te proberen en voorkomt dat overeenkomsten een onbedoelde status blijven houden zonder dat dit zichtbaar is.