Først rapporteret: august 2024
Sidst opdateret den
27. apr. 2026
Tekniske notifikationer for Adobe Sign står i rækkefølge nedenfor med ældste opdatering øverst og bevæger sig fremad i tid, efterhånden som du scroller ned på siden.
|
|
Fjernet fra den aktuelle liste: januar 2025 |
|---|
Den ældre Accept-Charset-overskrift fjernes fra alle webhook- og tilbagekaldelsesnotifikationer med udgivelsen november 2024.
Alle kunder, der af den ene eller anden grund er afhængige af denne overskrift, bør ændre deres kode for at tage højde for fraværet.
|
Først rapporteret: september 2024 |
Fjernet fra den aktuelle liste: januar 2025 |
|---|
|
Først rapporteret: november 2024 |
Fjernet fra den aktuelle liste: januar 2025 |
|---|
Med november 2024-udgivelsen er de redigerbare etiketter i Custom Workflow Designer blevet begrænset til 100 tegn. Denne grænse evalueres, når arbejdsforløbet oprettes eller opdateres.
Allerede eksisterende arbejdsforløb, der har etiketter på over 100 tegn, kan stadig sendes, men hvis arbejdsforløbet opdateres, skal etiketten reduceres til 100 tegn eller mindre, før den kan gemmes. Ugyldige etiketter vises med rødt for at gøre det nemmere at se dem.
Nye arbejdsforløb advarer om etiketgrænsen, før de gemmes.
Handling kræves
Det anbefales, at administratorer med kontrol over brugerdefinerede arbejdsforløb åbner og gennemgår hvert arbejdsforløb for at sikre, at de ikke har fejl på deres skabelon.
|
Først rapporteret: november 2024 |
Fjernet fra aktuel liste: februar 2025 |
|---|
Den nye modtageroplevelse indeholder forbedringer af underskrivelse for webbrowsere både til computere og mobilenheder. Denne nye oplevelse udrulles i løbet af de første måneder af 2025, men vil være tilgængelig i sandkassemiljøet i den første uge af december 2024.
|
Først rapporteret: December 2024 |
Fjernet fra aktuel liste: februar 2025 |
|---|
Adobe Acrobat Sign udskifter Adobe Acrobat Sign SSL-certifikatet 22. januar 2025.
Derudover udrulles et nyt SSL-certifikat, der skal understøtte ændringerne af WAF-netværket, som foretages januar 2025. Det nye certifikat påvirker direkte adgangen til tjenesten Acrobat Sign og skal installeres, før WAF kommer online.
Handling kræves
- Hver kundekonto, som eksplicit sikrer netværksaktivitet, skal medtage det nye WAF SSL-certifikat på sin liste over gemte certifikater.
- Har du brugerdefinerede integrationer med Acrobat Sign ved hjælp af enten SOAP eller REST API'er, og hvis nogen af disse integrationer har "fastgjort" den eksisterende offentlige nøgle, er ingen handling nødvendig.
- Bruger du Acrobat Signs SSL-certifikater til SSO, eller fastgør du selve certifikatet (eller bruger andre metoder), kan du finde de nye Acrobat Sign SSL-certifikater i Systemkrav for Adobe Acrobat Sign.
- Understøtter din SSO-konfiguration flere offentlige certifikater/kæder, kan du tilføje de nye certifikater nu og fjerne det gamle offentlige certifikat/kæde fra din konfiguration efter overgangen i januar.
- Hvis din SSO ikke understøtter flere offentlige certifikater/kæder, skal du synkronisere dit SSL-skift med Acrobat Sign den 22. januar 2025.
De nye SSL-certifikater vil være aktive 22. januar 2025.
|
Først rapporteret: september 2024 – opdateret: februar 2025 |
Fjernet fra nuværende liste: marts 2025 |
|---|
For at forbedre sikkerheden og robustheden i Adobe Acrobat Sign begynder vi at udrulle netværksændringer, der indeholder en WAF (web application firewall) i februar 2025. Disse ændringer vil sende trafik til Acrobat Sign-applikationsservere gennem WAF-tjenesten. Denne dirigering vil være usynlig for de fleste kunder. Brug påvirker ikke adgangen til Acrobat Sign fra nogen Adobe-klienter eller -integrationer.
Handling kræves
Ingen.
Denne ændring påvirker ikke kundeintegrationer, da Acrobat Sign API- og API-domænenavnene ikke ændres. Denne løsning er bagudkompatibel med de publicerede IP-intervaller.
Kunder, der har opdateret deres sikkerhedsenheder, behøver ikke at fortryde eller foretage andre ændringer.
Den aktuelle opdateringsplan er:
- Production Sandbox-opdateringer 24. februar 2025.
- Production-shards: IN1, JP1, AU1 og SG1 opdateres 3. marts 2025.
- Production-shards: NA2, NA3 og EU2 opdateres 6. marts 2025.
- Production-shards: NA1, NA4 og EU1 opdateres 11. marts 2025.
-
Indgangs- og udgangsadgang til Acrobat Sign
Acrobat Sign ophører ikke længere listen over serverindgangens IP-adresser som tidligere annonceret.
Serverindgangens og -udgangens IP-adresser som dokumenteret på siden Systemkrav for Acrobat Sign, forbliver synlige. -
Hvorfor foretager Acrobat disse ændringer?
Brugen af WAF forbedrer Acrobat Signs beskyttelse mod skadelig trafik og hjælper os med bedre at håndtere krav til sikkerhed, robusthed og overholdelse.
-
Jeg har en tilpasset integration i Acrobat Sign. Vil mit program blive påvirket?
Nej, vi forventer ikke, at nogen integrationer påvirkes negativt.
-
Er der nye IP-adresselister, der kan erstattes?
Nej.
Oplysningerne på siden Systemkrav for Acrobat Sign er stadig korrekte. -
Min organisation har implementeret netværksfiltrering ved hjælp af Acrobat Signs publicerede domæneliste for trafik fra vores firmanetværk. Er vi berørt?
Nej.
Netværksændringer, der er beskrevet her, påvirker ikke Acrobat Signs domæneliste som dokumenteret på siden Systemkrav for Acrobat Sign. Filtrering på domæneniveau påvirkes ikke. -
Min organisation anvender validering af IP-adresse til maillevering fra Acrobat Sign-servere. Er vi berørt?
Nej.
IP-intervallerne for udgående mailrelæer som angivet på siden Systemkrav for Acrobat Sign ændres ikke. -
Min organisation har konfigureret vores Acrobat Sign-konto for at begrænse adgangen til vores egne IP-adresser. Er vi berørt?
Nej.
Acrobat Sign kan konfigureres til at validere indgående trafik mod kundevalgte IP-adresser som beskrevet på siden Begræns adgangen til din konto ved hjælp af IP-adresseintervaller. Sådan brug påvirkes ikke af denne ændring. -
Min organisation har implementeret netværksfiltrering ved hjælp af Acrobat Signs publicerede liste over ingress-IP-adresser. Er vi berørt?
Nej.
Den nye WAF-konfiguration er bagudkompatibel med den eksisterende netværksarkitektur, så der skulle ikke være behov for yderligere justering af dine sikkerhedsenheder.
Bemærk:Bemærk, at dette henviser til filtrering på IP-niveau for det miljø, der er vært for din app. Filtrering på domæneniveau påvirkes ikke.
-
Jeg bruger Salesforce-integrationen med en eksplicit konfigureret IP-tilladelsesliste. Skal jeg gøre noget?
Nej.
WAF-installationen kræver ikke ændringer for eksisterende Salesforce-installationer på nuværende tidspunkt.
Den eksisterende konfiguration/proces, som beskrevet i hjælpedokumentationen, forbliver den samme, og administratorer skal følge alle trin for tilføjelse af IP til tilladelselsesliste.
ISV og Embed-partnere bør kontakte deres succesmanager med yderligere spørgsmål.
|
Først rapporteret: november 2024 – opdateret januar 2025 |
Fjernet fra aktuel liste: marts 2025 |
|---|
Afsendere kan give en ekstra visning af aftaler for mobilmodtagere, der kun viser feltet i den aftale, der er tilgængelig for modtageren.
Afsendere kan arrangere feltlisten, som de vil, og gruppere felter i logiske sektioner for at hjælpe underskriverne med at bevæge sig gennem feltinput med et minimum af rulning.
Modtagere har mulighed for at se den mobilvenlige feltliste eller den oprindelige PDF-visning med felterne placeret i dokumentindholdet.
Denne funktion er planlagt til at blive udgivet:
- Skal udrulles i sandkassemiljøet den 11. december 2024
- Skal udrulles i produktionsmiljøet den 4. marts 2025
|
Først rapporteret: maj 2024 |
Fjernet fra aktuel liste: marts 2025 |
|---|
Muligheden for at bruge et eksternt drev til at uploade filer er begrænset til OneDrive i den nye Anmod om signatur -oplevelse.
Det anbefales, at kunder, der bruger andre indstillinger til filoverførsel, bruger det leverandørspecifikke program til at levere et netværksdrev, der kan tilgås via den oprindelige filvælger på brugerens lokale system.
- Dropbox: https://www.dropbox.com/desktop
- Google Drev: 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
|
Først rapporteret: maj 2024 |
Fjernet fra aktuel liste: april 2025 |
|---|
Handling kræves
Alle integrationer og programmer, der bruger Adobe Acrobat Sign SOAP API, skal migreres til den nyeste REST API V6 før deaktiveringsdatoen for at sikre fortsat funktion.
Adgang til SOAP API fjernes for alle indlejringspartnere med start 1. marts 2025.
For at sikre fortsat funktion skal alle indlejringspartnere, der bruger Adobe Acrobat Sign SOAP API, migrere til den seneste REST API V6 før 1. marts 2025.
Læs venligst dokumenterne om REST v6 og migreringen som reference:
- Metoder i Adobe Acrobat Sign REST API version 6
- Overflytning fra SOAP
Hvis du har spørgsmål, bedes du kontakte din tildelte Adobe Acrobat Sign PSM.
Bemærk:
Denne opdatering gælder kun for Kommerciel-versionen af Acrobat Sign-tjenesten. Government Cloud-konti påvirkes ikke.
Opdatering gælder kun for siden Send (Anmod om e-signaturer). Strukturerede selvunderskrivelses-workflows er endnu ikke inkluderet.
|
Rapporteret første gang: marts 2024 – opdateret januar 2025 |
Fjernet fra aktuel liste: april 2025 |
|---|
Fra og med april 2025-versionen vil det moderne signaturanmodningsmiljø blive standardoplevelsen, når der oprettes en ny aftale.
- Brugerne vil ikke længere kunne skifte mellem det nye og det klassiske miljø, da switchlinks deaktiveres.
- Administratorer vil stadig have mulighed for at aktivere den klassiske oplevelse og gendanne switchlinks via administratormenuen.
- Kunder, der bruger Notarize -integrationen, påvirkes ikke af denne ændring.
|
Først rapporteret: marts 2024 – opdateret april 2025 |
Fjernet fra aktuel liste: april 2025 |
|---|
Bemærk:
Denne opdatering gælder kun for Kommerciel-versionen af Acrobat Sign-tjenesten. Government Cloud-konti påvirkes ikke.
Fra og med april 2025-versionen bliver det moderne miljø for Anmod om signatur den tilgængelige standardoplevelse, når der oprettes en ny Send i massevis-skabelon.
- Brugere kan ikke skifte tilbage til det klassiske miljø.
- Administratorer vil stadig have mulighed for at aktivere den klassiske oplevelse og gendanne switchlinks via administratormenuen.
|
Først rapporteret: februar 2025 |
Fjernet fra aktuel liste: april 2025 |
|---|
Fanen Konto, der er tilgængelig for Acrobat Sign-kontoniveauadministratorer, omdøbes til Administrator.
- Opdateringen gælder kun for det separate Acrobat Sign-miljø (Acrobat Sign Solutions og Acrobat Sign for Government).
- Opdateringen vil blive udrullet for det kommercielle miljø april 2025 og for det offentlige miljø maj 2025.
Bemærk, at ændringen kun er kosmetisk - der er ingen funktionelle ændringer, kun opdateringer af fanernes benævnelser.
Bemærk:
Etiketten Gruppe for gruppeadministratorer ændres ikke.
|
Først indrapporteret: marts 2025 |
Fjernet fra aktuel liste: april 2025 |
|---|
- Forbedret brugerlogin – Acrobat Sign har strømlinet login- og godkendelsesprocessen via Adobe Identity Management System (IMS).
- Brugerens organisationsprofil vælges automatisk under loginprocessen til dem, der er berettiget til Acrobat Sign-tjenesten (hvilket identificerer anmodningen som værende fra en Acrobat Sign-kilde)
- Brugere, der støder på fejl under login, har links i deres fejlmeddelelser for at kontakte deres Acrobat Sign-administratorer for at få hjælp.
- Alle brugere, der har fået tildelt en aktiv brugsret, men ikke er logget på tjenesten, vil få tilsendt op til to mailpåmindelser. (Dette gælder også for eksisterende inaktive brugere før udgivelsesdatoen )
Disse forbedringer forenkler login, reducerer friktion og forbedrer den generelle brugeroplevelse.
Tilgængelige miljøer: Kommerciel | Tilgængelige serviceniveauer: Acrobat Sign-løsninger | Konfigurationsområde: Aktiveret som standard, ikke konfigurerbar
|
Først rapporteret: marts 2025 – opdateret april 2025 |
Fjernet fra aktuel liste: juni 2025 |
|---|
Fra udgivelsen maj 2025 vil Acrobat Sign implementere strengere grænser for antallet af webhooks oprettet i konti på udviklerniveau.
Disse grænser er blevet valgt med vilje for at sikre pålideligheden af webhooks-infrastrukturen og bedre tilpasset til testarbejdsforløb.
|
Hvad ændrer sig? |
Forrige grænse |
Ny grænse |
Beskrivelse |
|---|---|---|---|
|
Antal aktive webhooks oprettet pr. kanal |
10 |
1 |
1 webhook er tilladt for kanalen pr. webhook-abonnementshændelse. |
|
Antal aktive webhooks, der er oprettet for en konto |
100 |
2 |
2 webhooks på kontoniveau er tilladt pr. webhook-abonnementshændelse. |
|
Antal aktive webhooks oprettet pr. gruppe |
100 |
2 |
2 webhooks på gruppeniveau er tilladt pr. gruppe pr. webhook-abonnementshændelse. |
|
Antal aktive webhooks, der er oprettet pr. aftaleressource |
50 |
1 |
1 webhook er tilladt pr. aftale pr. webhook-abonnementshændelse. |
|
Antal aktive webhooks oprettet pr. bruger |
100 |
1 |
1 webhook er tilladt pr. bruger pr. webhook-abonnementshændelse. |
Tilgængelige miljøer: Kommercielt | ;Tilgængelige tjenesteniveauer: Udvikler | Konfigurationsomfang: Aktiveret som standard; kan ikke konfigureres
|
Først indrapporteret: marts 2025 |
Fjernet fra aktuel liste: april 2025 |
|---|
Acrobat Sign-kunder kan nu abonnere på tjenesten Acrobat Sign Webhook for at modtage proaktive meddelelser om afbrydelser, forstyrrelser og vedligeholdelseshændelser via Adobe Status Portal.
Administrer og tilføj abonnementer her: Hjælp til abonnement på Adobe Status.
Bemærk, at tjenesten Adobe Acrobat Sign er angivet under overskriften Document Cloud:
|
Først rapporteret: marts 2025 |
Fjernet fra aktuel liste: juni 2025 |
|---|
I maj 2025-versionen optimerer vi GET/aftale-API'en for at reducere svartiderne markant - vores interne test viser forbedringer på op til 10x.
Hvad er ændret
- Mindre sidestørrelser: For at understøtte disse forbedringer har vi reduceret det maksimale antal aftaler, der returneres pr. anmodning, til 500, men denne grænse kan ændre sig i fremtidige versioner. Hvert svar omfatter:
- Det faktiske antal returnerede aftaler
- Et link til den næste side med resultater (hvis det findes)
- Dynamisk resultattælling: Du kan stadig anmode om et bestemt antal aftaler, men API'en returnerer så mange, som tjenesten kan levere. Hvert svar omfatter:
Hvad du kan forvente
I nogle tilfælde kan der være en lille forsinkelse mellem at oprette en aftale og hente den ved hjælp af GET /agreements API. Denne forsinkelse er typisk meget kort. En opfølgningsanmodning bør returnere den nye aftale.
Tilgængelige miljøer: Kommercielt, Offentligt | Tilgængelige tjenesteniveauer: Acrobat Sign Services | Offentligt Konfigurationsomfang: Slået til som standard: Kan ikke konfigureres
|
Først rapporteret: april 2025 |
Fjernet fra aktuel liste: august 2025 |
|---|
Alle konti, der bruger tjenesten Acrobat Sign for Government, vil få adgang til det nye miljø for Anmod om underskrift samt til flere nyligt oprettede funktioner, som afhænger af det:
- eWitnessing
- Begrænset adgang til aftaler
- Gennemtving signaturtype
- Identitetstjek
- CC'er pr. modtager
- Modtagerlisten og modtageregenskaberne kan redigeres efter oprettelse
|
Først rapporteret: september 2024 |
Fjernet fra den aktuelle liste: februar 2026 |
|---|
Handling kræves
Alle kunder, der bruger API'en, skal opdatere deres API'er, sådan at version 6-slutpunkterne anvendes så hurtigt som muligt for at sikre uafbrudt tilgængelighed.
Version 1 til og med 4 af Acrobat Sign REST API er blevet udfaset og fjernes fra tjenesten 1. december 2025.
Opdatering af API'er kan kræve en betydelig indsats, så alle kunder opfordres på det kraftigste til at få overblik over og budgettere deres opdatering så hurtigt som muligt, så supporten kan engageres fuldt ud og løse eventuelle spørgsmål eller problemer inden skæringsdatoen i december 2025.
Selvom REST API v1-4 udfases, vil de fortsat fungere, og dine programmer vil fortsat virke indtil den 1. december 2025, hvor REST API v1-4 fjernes.
Efter den 1. december 2025 vil programmer, der er lavet på REST API v1-4, ophøre med at fungere.
|
Først rapporteret: april 2025 |
Fjernet fra den aktuelle liste: februar 2026 |
|---|
Alle konti, der bruger tjenesten Acrobat Sign for Government, vil få adgang til det nye miljø for Anmod om underskrift samt til flere nyligt oprettede funktioner, som afhænger af det:
- eWitnessing
- Begrænset adgang til aftaler
- Gennemtving signaturtype
- Identitetstjek
- CC'er pr. modtager
- Modtagerlisten og modtageregenskaberne kan redigeres efter oprettelse
|
Først rapporteret: september 2024 – opdateret april 2025 |
Fjernet fra den aktuelle liste: februar 2026 |
|---|
Webhook 2.0-infrastrukturen er blevet udrullet til alle kunder, og efter dens fuldførelse udfases underskrivernotifikationer. Som et resultat leverer parameteren webhookNotificationApplicableUsers for webhook-elementet ikke længere brugbare data og fjernes fra alle webhook-elementer.
Sandkasse-miljøerne opdateres i juni-udgivelsen.
Produktionsmiljøerne opdateres i udgivelsen juli 2025.
Det afsendende bruger-id og mailen kan findes ved hjælp af parametrene initiatingUserId og initiatingUserEmail i meddelelseselementet.
|
Først rapporteret: august 2025 – opdateret: oktober 2025 |
Fjernet fra den aktuelle liste: februar 2026 |
|---|
For at hjælpe med at holde systemet stabilt og forbedre ydeevnen vil Acrobat Sign indføre en grænse for polling i versionen fra 4. november 2025 (version 16.2.1). Denne ændring begrænser, hvor ofte klientprogrammer kan foretage polling af specifikke API-endepunkter.
- Kunder har to måneder efter 16.2.1-udgivelsen til at implementere de anbefalede ændringer af polling i deres kode. I dette tidsrum vil systemet kun LOGGE hændelser for polling-intervallets grænse.
- Efter december 2025 vil beskyttelsespolitikkerne for polling blive ændret til HÅNDHÆV (ENFORCE), og fejlene vil begynde at blive udløst for brugerne.
Polling med høj frekvens skaber en unødvendig belastning på backend-systemer, hvilket resulterer i forringet ydeevne og langsommere svartider. API-udviklere opfordres til at skifte til webhooks for at få realtidsopdateringer.
Hvad der ændres
Denne polling-politik gælder for alle GET API-endepunkter.
Eksempler på berørte slutpunkter
Statushentning:
- GET /agreements/{agreementId) – henter den aktuelle status for en aftale.
- GET /agreements/{agreementId)/documents/{documentId) – henter filstrømmen af et dokument i en aftale.
Liste:
- GET /agreements – henter aftaler for brugeren.
- GET /agreements/{agreementId)/events – henter begivenhedsoplysninger for en aftale.
Der vil blive anvendt en grænse for, hvor ofte den aktuelle bruger kan foretage det samme API-kald til Acrobat Sign-tjenesten. Der returneres en fejl, hvis det samme kald foretages inden for det minimale polling-interval af den samme aktuelle bruger.
Oplysninger om polling-politik
- Minimumsinterval for objekt-polling (MOPI): Standard-MOPI varierer afhængigt af tjenesteniveauet og programtyperne:
- Acrobat Sign-partnerprogrammer: MOPI for en partnerapp bestemmes af niveauet for brugerens konto.
- GLOBAL/ENTERPRISE-niveau: 3 opkald pr. interval på 1 minut
- Alle andre niveauer: 1 unikt opkald pr. interval på 10 minutter
- Kundeprogrammer på Global/Enterprise-konti: Tre identiske opkald pr. interval på 1 minut.
- Kundeprogrammer på udviklerkonti: 1 unikt kald pr. interval på 10 minutter.
- Acrobat Sign-partnerprogrammer: MOPI for en partnerapp bestemmes af niveauet for brugerens konto.
- Duplikerede anmodninger i MOPI: Hvis den samme aktuelle bruger foretager identiske GET-anmodninger (samme sti og sidehoveder) ud over hvad deres niveau i MOPI tillader, vil systemet returnere:
- Statuskoden 304 Ikke ændret til HTTP-betingede anmodninger ved hjælp af en ETag.
- 429 For mange anmodninger statuskode med en retry-after for andre anmodninger.
- ETag-håndtering: Denne politik gælder, når ETag-værdier angives i If-None-Match -headeren for endepunkter, der allerede understøtter 304 Ikke ændret .
Handling kræves
Webhooks: Hvis dit program kræver opdateringer i næsten realtid, skal du bruge webhooks i stedet for polling. Webhooks giver en mere effektiv og skalerbar måde at modtage rettidige opdateringer på.
Hvis webhooks ikke kan implementeres, bør programmer implementere caching-mekanismer på klientsiden for at gemme og genbruge API-svar. Når der modtages et 304 Ikke ændret-svar, bør de cachede data bruges i stedet for at foretage et nyt API-kald.
Kunder har to måneder efter 16.2.1-udgivelsen til at implementere de anbefalede ændringer af polling i deres kode. I dette tidsrum vil systemet LOGGE hændelser for polling-intervallets grænse.
Efter december 2025 vil beskyttelsespolitikkerne for polling blive ændret til HÅNDHÆV, og fejlene vil begynde at udløses for brugerne.
Kontakt din CSM, hvis du har brug for hjælp eller har spørgsmål.
Sandkasse-miljøet vil aktivere politikken for polling til LOG fejl den 17. september 2025 og indstille den til HÅNDHÆV den 25. september 2025.
|
Først rapporteret: august 2025 |
Fjernet fra den aktuelle liste: februar 2026 |
|---|
For at understøtte FedRAMP CSP-krav aktiverer vi IPv6-protokollen på vores miljø for Acrobat Sign for Government:
- 2001:489a:3102:4::160/124 (IPv6)
- 2001:489a:3102:4::150/124 (IPv6)
|
Først rapporteret: september 2025 |
Fjernet fra den aktuelle liste: februar 2026 |
|---|
Sprogindstillingsvalideringen er blevet strengere ved oprettelse af en aftale via API. Hvis en aftales sprog ikke er tilladt af kontoens politikker, afviser API'en anmodningen med en klar fejl. Dette reducerer utilsigtede sproguoverensstemmelser og holder modtageroplevelser i overensstemmelse med godkendte indstillinger.
Hvem er påvirket
- Konti, der indstiller aftalesproget i API-anmodninger.
- Konti, der begrænser tilgængelige sprog eller forbyder sprogændringer under afsendelse.
Hvad er ændret
Når indstillingen DISPLAY_LOCALE_INFO_DURING_SEND er aktiveret (GLOBAL-niveau), håndhæver API'en:
- Aftalens sprog skal være inkluderet i brugerens AVAILABLE_LOCALES.
- Hvis ALLOW_LOCALE_SELECTION_DURING_SEND er falsk, skal aftalens sprog matche brugerens AGREEMENT_LOCALE.
Overtrædelser får POST /agreements til at mislykkes med: "Sprog er enten ugyldigt eller mangler."
Almindelig fejl og hvordan man retter den
Fejl: "Sprog er enten ugyldigt eller mangler."
- Kontrollér det sprog, der bruges i API-anmodningen (for eksempel en_US).
- Bekræft, at sproget vises i AVAILABLE_LOCALES for den kaldende bruger.
- Hvis ALLOW_LOCALE_SELECTION_DURING_SEND er falsk, skal du sikre, at anmodningens sprog matcher AGREEMENT_LOCALE.
- Hvis fleksibilitet på tværs af regioner er påkrævet, skal du aktivere sprogvalg ved afsendelse (se Påkrævet handling).
Bagudkompatibilitet
- Før denne ændring kunne nogle anmodninger med uoverensstemmende sprog lykkes. Sådanne anmodninger mislykkes nu med en klar fejl, når valideringer ikke består.
- Ingen API-skemaændringer; valideringsadfærd ændres kun, når DISPLAY_LOCALE_INFO_DURING_SEND er aktiveret.
Handling kræves
Administratorer og API-integratorer bør gøre et af følgende:
- Tilpas sproget i API-anmodninger med AVAILABLE_LOCALES, og – hvis ALLOW_LOCALE_SELECTION_DURING_SEND er falsk – skal AGREEMENT_LOCALE matches nøjagtigt
- eller -
- Tillad sprogvalg ved afsendelse ved at indstille:
- ALLOW_LOCALE_SELECTION_DURING_SEND = sand
- CAN_CHANGE_UI_LOCALE = sand
|
Først indrapporteret: December 2025 |
Fjernet fra den aktuelle liste: februar 2026 |
|---|
Adobe Acrobat Sign udskifter Adobe Acrobat Sign SSL-certifikatet 7. januar 2026.
Handling kræves
- Har du brugerdefinerede integrationer med Acrobat Sign ved brug af REST API'er, og hvis nogen af disse integrationer har "fastgjort" den eksisterende offentlige nøgle, er ingen handling nødvendig.
- Bruger du Acrobat Signs SSL-certifikater til SSO, eller fastgør du selve certifikatet (eller bruger andre metoder), kan du finde de nye Acrobat Sign SSL-certifikater i Systemkrav for Adobe Acrobat Sign.
- Understøtter din SSO-konfiguration flere offentlige certifikater/kæder, kan du tilføje de nye certifikater nu og fjerne det gamle offentlige certifikat/kæde fra din konfiguration efter overgangen i januar.
- Hvis din SSO ikke understøtter flere offentlige certifikater/kæder, skal du synkronisere dit SSL-skift med Acrobat Sign den 7. januar 2026.
De nye SSL-certifikater vil være aktive 7. januar 2026.
|
Først rapporteret: september 2024 – opdateret april 2025 |
Nuværende |
|---|
Webhook 2.0-infrastrukturen er blevet udrullet til alle kunder, og efter dens fuldførelse udfases underskrivernotifikationer. Som et resultat leverer parameteren webhookNotificationApplicableUsers for webhook-elementet ikke længere brugbare data og fjernes fra alle webhook-elementer.
Sandkasse-miljøerne opdateres i juni-udgivelsen.
Produktionsmiljøerne opdateres i udgivelsen juli 2025.
Det afsendende bruger-id og mailen kan findes ved hjælp af parametrene initiatingUserId og initiatingUserEmail i meddelelseselementet.