Først rapportert: August 2024
Sist oppdatert
9. feb. 2026
Adobe Sign tekniske varsler er ordnet nedenfor med den eldste oppdateringen øverst, og ruller fremover i tid når du blar ned på siden.
|
|
Fjernet fra Gjeldende-liste: Januar 2025 |
|---|
Den eldre Accept-Charset-toppteksten fjernes fra alle webhook- og callback-varsler i november 2024-utgivelsen.
Alle kunder som er avhengig av denne toppteksten, bør refaktorere koden for å ta hensyn til at den fjernes.
|
Først rapportert: September 2024 |
Fjernet fra Gjeldende-liste: Januar 2025 |
|---|
|
Først rapportert: November 2024 |
Fjernet fra Gjeldende-liste: Januar 2025 |
|---|
I november 2024-utgivelsen har de redigerbare etikettene i Tilpasset arbeidsflytutforming blitt begrenset til 100 tegn. Denne grensen evalueres når arbeidsflyten opprettes eller oppdateres.
Forhåndseksisterende arbeidsflyter som har etiketter på over 100 tegn kan fremdeles sendes, men hvis arbeidsflyten oppdateres må etiketten reduseres til 100 tegn eller mindre før den kan lagres. Motstridende etiketter er merket med rødt for enkel oppdagelse.
Nye arbeidsflyter varsler om etikettgrensen før de lagres.
Handling kreves
Det anbefales at administratorer med kontroll over tilpassede arbeidsflyter åpner og gjennomgår hver arbeidsflyt for å sikre at de ikke har feil i malen.
|
Først rapportert: November 2024 |
Fjernet fra gjeldende-liste: februar 2025 |
|---|
Den nye mottakeropplevelsen inneholder signeringsforbedringer for både stasjonære og mobile web-nettlesere.Denne nye opplevelsen rulles ut de første månedene i 2025, men er tilgjengelig i Sandbox-miljøet den første uken i desember 2024.
|
Først rapportert: Desember 2024 |
Fjernet fra gjeldende-liste: februar 2025 |
|---|
Adobe Acrobat Sign vil rotere Adobe Acrobat Sign SSL-sertifikatet den 22. januar 2025.
I tillegg blir et nytt SSL-sertifikat distribuert for å støtte waf-nettverksendringene som gjøres i januar 2025. Dette nye sertifikatet påvirker tilgangen til Acrobat Sign-tjenesten direkte, og må installeres før WAF-en går på nett.
Handling kreves
- Hver kundekonto som eksplisitt sikrer nettverksaktivitet, må inkludere det nye WAF SSL-sertifikatet i sin liste over lagrede sertifikater.
- Hvis du har bygd egne integrasjoner med Acrobat Sign ved bruk av SOAP- eller REST-API-er, og hvis noen av disse integrasjonene har «festet» den eksisterende offentlige nøkkelen, er det ikke nødvendig å gjøre noe.
- Hvis du bruker acrobat sign sine SSL-Sertifikater for SSO, eller hvis du fester sertifikatet selv (eller bruker andre metoder), kan du finne de nye acrobat sign SSL-Sertifikatene i adobe acrobat sign systemkrav.
- Hvis SSO-konfigurasjonen støtter flere offentlige sertifikater/kjeder, kan du nå legge til de nye sertifikatene og fjerne det gamle offentlige sertifikatet/kjeden fra konfigurasjonen etter byttet i januar.
- Hvis din SSO ikke støtter flere offentlige sertifikater/kjeder, må du synkronisere din SSL-bryter med Acrobat Sign den 22. januar 2025.
De nye SSL-sertifikatene blir aktive fra 22. januar 2025.
|
Først rapportert: september 2024 – oppdatert: februar 2025 |
Fjernet fra gjeldende liste: mars 2025 |
|---|
For å forbedre Adobe Acrobat Sign-tjenestens sikkerhet og robusthet, begynner vi utrullering av nettverksendringer for å inkludere en nettapplikasjonsbrannmur (WAF) i februar 2025. Disse endringene ruter trafikk til Acrobat Sign-programservere via WAF-tjenesten. Denne rutingen blir usynlig for de fleste kundene. Bruken forstyrrer ikke tilgangen til Acrobat Sign fra noen Adobe-klienter eller -integrasjoner.
Handling kreves
Ingen.
Denne endringen påvirke kundeintegreringer, siden Acrobat Sign API- og API-domenenavn ikke endres. Denne løsningen er bakoverkompatibel med de publiserte IP-områdene.
Kunder som har oppdatert sikkerhetsenhetene sine, trenger ikke å tilbakestille eller gjøre andre endringer.
Gjeldende oppdateringsplan er:
- Sandbox-oppdateringer for produksjon 24. februar 2025.
- Produksjonsfragmenter: IN1, JP1, AU1 og SG1 oppdateres 3. mars 2025.
- Produksjonsfragmenter: NA2, NA3 og EU2 oppdateres 6. mars 2025.
- Produksjonsfragmenter: NA1, NA4 og EU1 oppdateres 11. mars 2025.
-
Inngående og utgående tilgang til Acrobat Sign
Acrobat Sign avvikler ikke lenger listen over inngående IP-adresser for servere som tidligere kunngjort.
Serverens inn- og utgående IP-adresser, som dokumentert på Systemkrav for Acrobat Sign-siden, forblir gjeldende. -
Hvorfor gjør Acrobat disse endringene?
Bruk av WAF forbedrer Acrobat Signs beskyttelse mot skadelig trafikk, og hjelper oss med å bedre håndtere krav til sikkerhet, robusthet og samsvar.
-
Jeg har en tilpasset integrering i Acrobat Sign. Blir programmet mitt påvirket?
Nei, vi forventer ikke at integreringer blir negativt påvirket.
-
Finnes det nye IP-adresselister som kan erstattes?
Nei.
Informasjonen på systemkrav for acrobat sign-siden forblir nøyaktig. -
Min organisasjon har implementert nettverksfiltrering med Acrobat Signs publiserte domeneliste for trafikk fra vårt bedriftsnettverk. Er vi berørt?
Nei.
Nettverksendringene beskrevet her påvirker ikke acrobat sign sin domene-liste, som dokumentert på systemkrav for acrobat sign-siden.Filtrering på domenenivå påvirkes ikke. -
Organisasjonen min bruker IP-adressevalidering for e-postlevering fra Acrobat Sign-servere. Er vi berørt?
Nei.
IP-områdene for utgående e-post-reléer, som oppført på systemkrav for acrobat sign-siden, endres ikke. -
Organisasjonen min har konfigurert Acrobat Sign-kontoen for å begrense tilgangen til våre egne IP-adresser. Er vi berørt?
Nei.
acrobat sign kan konfigureres til å validere innkommende trafikk mot kunde-valgte IP-adresser, som beskrevet på siden Begrens tilgang til kontoen din ved hjelp av IP-adresseområder.Denne endringen berører ikke slik bruk. -
Organisasjonen min har implementert nettverksfiltrering ved hjelp av Acrobat Signs publiserte liste over inngående IP-adresser. Er vi berørt?
Nei.
Den nye WAF-konfigurasjonen er bakoverkompatibel med den eksisterende nettverksarkitekturen, det er ikke nødvendig med ekstra tuning av sikkerhetsenhetene dine.
Merk:Merk at dette refererer til filtrering på IP-nivå for miljøet som er vert for applikasjonen din. Filtrering på domenenivå påvirkes ikke.
-
Jeg bruker Salesforce-integrasjonen med eksplisitt konfigurert IP-tillatelsesliste. Må jeg gjøre noe?
Nei.
WAF-installasjonen krever ingen endringer for eksisterende Salesforce-installasjoner på dette tidspunktet.
Den eksisterende konfigurasjonen/prosessen, som beskrevet i hjelpedokumentasjonen, forblir den samme. Administratorer bør følge alle trinn for å sette IP på inkluderingsliste.
ISV- og Embed-partnere må kontakte sin kundeansvarlige hvis de har flere spørsmål.
|
Først rapportert: november 2024 – Oppdatert: januar 2025 |
Fjernet fra gjeldende liste: mars 2025 |
|---|
Avsendere kan gi en ekstra visning av avtaler for mobile mottakere som bare viser feltet i avtalen som er tilgjengelig for mottakeren.
Avsendere kan ordne feltlisten slik de vil, og gruppere felt i logiske deler for å hjelpe underskriverne med å bevege seg gjennom feltinndataene med et minimum av rulling.
Mottakere kan velge å vise listen over mobilvennlige felt eller den opprinnelige PDF-visningen med feltene plassert i dokumentinnholdet.
Denne funksjonen er planlagt utgitt:
- Distribueres i Sandbox-miljøet 11. desember 2024
- Skal installeres på produksjonsmiljøet 4. mars 2025
|
Først rapportert: Mai 2024 |
Fjernet fra gjeldende liste: mars 2025 |
|---|
Alternativet for å bruke en ekstern stasjon for å laste opp filer vil være begrenset til OneDrive bare i den nye Be om signatur-opplevelsen.
Det anbefales at kunder som bruker andre alternativer for filopplasting, bruker den leverandørspesifikke applikasjonen for å tilby en nettverksstasjon som kan nås gjennom den opprinnelige filvelgeren på brukerens lokale system.
- Dropbox: https://www.dropbox.com/desktop
- Google Disk: 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 rapportert: Mai 2024 |
Fjernet fra gjeldende liste: april 2025 |
|---|
Handling kreves
Alle integrasjoner og programmer som bruker Adobe Acrobat Sign SOAP API, må, for å sikre fortsatt funksjon, migrere til den seneste REST API V6 før deaktiveringsdato.
Tilgang til SOAP API blir fjernet for alle innbyggingspartnere med start 1. mars 2025.
For å sikre fortsatt funksjonalitet, må alle integreringspartnere som bruker Adobe Acrobat Sign SOAP API migrere til nyeste REST API V6 før 1. mars 2025.
Gjennomgå REST v6 og migreringsdokumentasjonen for referanse:
- Adobe Acrobat Sign REST API, versjon 6-metoder
- Overgang fra SOAP
Hvis du har spørsmål, kan du kontakte din utpekte Adobe Acrobat Sign PSM.
Merk:
Denne oppdateringen gjelder kun for Kommersiell versjonen av Acrobat Sign-tjenesten. Government Cloud-kontoene påvirkes ikke.
Denne oppdateringen gjelder bare Send (Anmod e-signaturer)-siden.Strukturerte selvsignerende arbeidsflyter er ikke inkludert ennå.
|
Først rapportert: mars 2024 – Oppdatert: januar 2025 |
Fjernet fra gjeldende liste: april 2025 |
|---|
Fra og med april 2025-utgivelsen vil det moderne Be om signatur-miljøet bli standardopplevelsen når du oppretter en ny avtale.
- Brukere vil ikke lenger kunne veksle mellom det nye og det klassiske miljøet, fordi vekslekoblinger blir deaktivert.
- Administratorer har fremdeles muligheten til å aktivere den klassiske opplevelsen og gjenopprette bytte av koblinger gjennom administratormenyen.
- Kunder som bruker Notarize-integreringen blir ikke påvirket av denne endringen.
|
Først rapportert: mars 2024 - oppdatert april 2025 |
Fjernet fra gjeldende liste: april 2025 |
|---|
Merk:
Denne oppdateringen gjelder kun for Kommersiell versjonen av Acrobat Sign-tjenesten. Government Cloud-kontoene påvirkes ikke.
Fra april 2025-utgivelsen vil det moderne Request Signature-miljøet bli standardopplevelsen som er tilgjengelig når du oppretter en ny Send i bulk-mal.
- Brukere vil ikke kunne bytte tilbake til det klassiske miljøet.
- Administratorer vil ha muligheten til å aktivere den klassiske opplevelsen og Gjenopprett byttelenkene gjennom administratormenyen.
|
Først rapportert: februar 2025 |
Fjernet fra gjeldende liste: april 2025 |
|---|
Konto-fanen, som er tilgjengelig for Acrobat Sign-kontoadministratorer, endrer navn til Administrator.
- Denne oppdateringen gjelder kun for Acrobat Sign Standalone-miljøet (Acrobat Sign Solutions og Acrobat Sign for Government).
- Oppdateringen blir implementert for det kommersielle miljøet i april 2025 og for regjeringsmiljøet i mai 2025.
Merk at denne endringen er rent kosmetisk. Det er ingen funksjonelle endringer, bare oppdateringer av faneetikettene.
Merk:
Gruppe-etiketten for administratorer på gruppenivå vil ikke endres.
|
Først rapportert: Mars 2025 |
Fjernet fra gjeldende liste: april 2025 |
|---|
- Forbedret brukerpåloggingsopplevelse – Acrobat Sign har strømlinjeformet påloggings- og godkjenningsprosessen gjennom Adobe Identity Management System (IMS).
- Organisasjonsprofilen til brukeren blir automatisk valgt under påloggingsprosessen til profiler som er berettiget med Acrobat Sign-tjenesten (identifiserer forespørselen som om den kommer fra en Acrobat Sign-kilde)
- Brukere som støter på feil under pålogging, vil ha koblinger i feilmeldingene sine for å kontakte Acrobat Sign-administratorene for å få hjelp.
- Alle brukere som har fått tildelt en aktiv rettighet, men som ikke er logget på tjenesten, får tilsendt opptil to e-postpåminnelser. (Dette gjelder også eksisterende inaktive brukere før utgivelsesdatoen )
Disse forbedringene forenkler pålogging, reduserer friksjon og forbedrer den generelle brukeropplevelsen.
Tilgjengelige miljøer: Kommersiell | Tilgjengelige tjenestenivåer: Acrobat Sign Solutions | Konfigurasjonsomfang: aktivert som standard; ikke konfigurerbar
|
Først rapportert: mars 2025 – Oppdatert april 2025 |
Fjernet fra gjeldende liste: juni 2025 |
|---|
Fra og med mai 2025-utgivelsen vil Acrobat Sign implementere strengere grenser for antallet webhooks som er opprettet i Developer-kontoer.
Disse grensene er valgt med hensikt for å sikre påliteligheten til webhooks-infrastrukturen og er bedre tilpasset for testing av arbeidsflyter.
|
Dette endres |
Forrige grense |
Ny grense |
Beskrivelse |
|---|---|---|---|
|
Antall aktive webhooks opprettet per kanal |
10 |
1 |
1 webhook er tillatt for kanalen per webhook-abonnementshendelse. |
|
Antall aktive webhooks opprettet for en konto |
100 |
2 |
2 webhook på kontonivå er tillatt per webhook-abonnementshendelse. |
|
Antall aktive webhooks opprettet per gruppe |
100 |
2 |
2 gruppenivåer med webhook er tillatt per gruppe per webhook-abonnementshendelse. |
|
Antall aktive webhooks opprettet per avtaleressurs |
50 |
1 |
1 webhook er tillatt per avtale per webhook-abonnementshendelse. |
|
Antall aktive webhooks opprettet per bruker |
100 |
1 |
1 webhook er tillatt per bruker per webhook-abonnementshendelse. |
Tilgjengelige miljøer: kommersiell | Tilgjengelige tjenestenivåer: utvikler | Konfigurasjonsomfang: aktivert som standard; kan ikke konfigureres
|
Først rapportert: Mars 2025 |
Fjernet fra gjeldende liste: april 2025 |
|---|
Acrobat Sign-kunder kan nå abonnere på Acrobat Sign Webhook-tjenesten for å motta proaktive varsler om nedetid, avbrudd og vedlikeholdshendelser via Adobe Status Portal.
Behandle og legg til abonnementer her: Hjelp for status på Adobe-abonnement.
Vær oppmerksom på at tjenesten Adobe Acrobat Sign er oppført under overskriften Document Cloud:
|
Først rapportert: mars 2025 |
Fjernet fra gjeldende liste: juni 2025 |
|---|
I mai 2025-utgivelsen er GET/agreemenst API optimalisert for å redusere responstiden betraktelig – vår interne testing viser opptil 10 ganger raskere responstid.
Endringer
- Mindre sidestørrelser: For å støtte disse forbedringene har vi redusert det maksimale antallet avtaler som returneres per forespørsel til 500, men denne grensen kan endres i fremtidige utgivelser. Hvert svar inkluderer:
- Det faktiske antallet avtaler som er returnert
- En kobling til neste resultatside (hvis tilgjengelig)
- Dynamisk resultattelling: Du kan fortsatt be om et spesifikt antall avtaler, men API-et vil returnere så mange som tjenesten kan tilby. Hvert svar inkluderer:
Dette kan du forvente
I noen tilfeller kan det gå litt tid mellom du oppretter en avtale og når du kan hente den ved hjelp av GET/agreements API. Denne forsinkelsen er vanligvis svært kort – en oppfølgingsforespørsel skal returnere den nye avtalen.
Tilgjengelige miljøer: kommersiell, offentlig | Tilgjengelige tjenestenivåer: Acrobat Sign Services, Government | Konfigurasjonsomfang: aktivert som standard; kan ikke konfigureres
|
Først rapportert: april 2025 |
Fjernet fra gjeldende liste: august 2025 |
|---|
Alle kontoer som bruker Acrobat Sign for Government-tjenesten vil få tilgang til å aktivere det nye Request Signature-miljøet, sammen med flere funksjoner som nylig er opprettet og som er avhengige av det:
- e-bevitning
- Begrenset tilgang til avtaler
- Håndhev signaturtype
- Identitetskontroll
- Kopimottakere per mottaker
- Mottakerliste- og mottakeregenskapene kan redigeres etter redigering
|
Først rapportert: September 2024 |
Fjernet fra gjeldende liste: feb 2026 |
|---|
Handling kreves
Alle kunder som bruker API-et må oppdatere API-ene sine til å bruke versjon 6-endepunktene så snart som mulig for å sikre uavbrutt tilgjengelighet.
Versjon 1–4 av Acrobat Sign REST API har blitt avviklet og vil fjernes fra tjenesten 1. desember 2025.
Oppdatering av API-er kan innebære betydelige anstrengelser, så alle kunder oppfordres på det sterkeste til å planlegge oppdateringene sine så snart som mulig, slik at støtteteamet kan bidra til å løse eventuelle spørsmål eller problemer som måtte oppstå før sluttdatoen i desember 2025.
Selv om REST API versjon 1–4 blir avviklet, vil de fortsette å fungere, og programmene deres vil fortsette å fungere helt til 1. desember 2025, når REST API versjon 1–4 fjernes.
Etter 1. desember 2025 vil alle programmer som er bygd på REST API versjon 1–4 slutte å fungere.
|
Først rapportert: April 2025 |
Fjernet fra gjeldende liste: feb 2026 |
|---|
Alle kontoer som bruker Acrobat Sign for Government-tjenesten vil få tilgang til å aktivere det nye Request Signature-miljøet, sammen med flere funksjoner som nylig er opprettet og som er avhengige av det:
- e-bevitning
- Begrenset tilgang til avtaler
- Håndhev signaturtype
- Identitetskontroll
- Kopimottakere per mottaker
- Mottakerliste- og mottakeregenskapene kan redigeres etter redigering
|
Først rapportert: september 2024 – Oppdatert april 2025 |
Fjernet fra gjeldende liste: feb 2026 |
|---|
Webhook 2.0-infrastrukturen er rullet ut til alle kunder, med dette er underskrivervarsler avviklet. Dette fører til at parameteren webhookNotificationApplicableUsers for webhook-nyttelasten ikke lenger gir noen nyttige data. Den fjernes fra alle webhook-nyttelaster.
Sandbox-miljøet blir oppdatert i juni-utgivelsen.
Produksjonsmiljøene blir oppdatert i juli 2025-utgivelsen.
Finner senderens userID og e-postadresse ved hjelp av parameterne initiatingUserId og initiatingUserEmail i varslingsnyttelasten.
|
Først rapportert: august 2025 - Oppdatert oktober 2025 |
Fjernet fra gjeldende liste: feb 2026 |
|---|
For å opprettholde systemstabilitet og forbedre ytelsen vil Acrobat Sign innføre en spørringsterskel i utgivelsen 4. november 2025 (versjon 16.2.1). Denne endringen begrenser hvor ofte klientprogrammer kan spørre spesifikke API-endepunkter.
- Kundene har to måneder etter 16.2.1-utgivelsen til å implementere de anbefalte avspørringsendringene i koden sin. I dette tidsvinduet vil systemet kun LOGGE spørringsintervallhendelsene.
- Etter desember 2025 vil beskyttelsespolicyer for spørring bli byttet til HÅNDHEV, og feilene vil begynne å utløses for brukere.
Høyfrekvent spørring skaper unødvendig belastning på backend-systemer, noe som resulterer i redusert ytelse og tregere responstider. API-utviklere oppfordres til å bytte til webhooks for sanntidsoppdateringer.
Hva som endres
Denne spørringspolicyen gjelder for alle GET API-endepunkter.
Eksempler på berørte endepunkter
Statushenting:
- GET /agreements/{agreementId) – Henter gjeldende status for en avtale.
- GET /agreements/{agreementId)/documents/{documentId) – Henter filstrømmen til et dokument i en avtale.
Listing:
- GET /agreements – Henter avtaler for brukeren.
- GET /agreements/{agreementId)/events – Henter hendelsesinfo for en avtale.
Det vil bli anvendt en grense for hvor ofte den effektive brukeren kan gjøre samme API-kall til Acrobat Sign-tjenesten. En feil returneres hvis samme kall gjøres innenfor det minste spørringsintervallet av samme effektive bruker.
Detaljer om spørringspolicy
- Minimum Object Polling Interval (MOPI): Standard MOPI varierer avhengig av tjenestenivå og app-typer:
- Acrobat Sign-partnerapper: MOPI for en partner-app bestemmes av nivået til brukerens konto.
- GLOBAL/ENTERPRISE-nivå: 3 anrop per ett minutts intervall
- Alle andre nivåer: 1 unikt anrop per ti minutters intervall
- Kunde-apper under Global/Enterprise-kontoer: Tre identiske anrop per ett minutts intervall.
- Kunde-apper under Developer-kontoer: Ett unikt anrop per 10 minutters intervall.
- Acrobat Sign-partnerapper: MOPI for en partner-app bestemmes av nivået til brukerens konto.
- Dupliserte forespørsler innenfor MOPI: Hvis samme effektive bruker gjør identiske get-forespørsler (samme sti og overskrifter) mer enn nivået deres tillater innenfor MOPI, vil systemet returnere:
- 304 Not Modified statuskode for HTTP-betingede forespørsler som bruker en ETag.
- 429 Too Many Requests statuskode med en retry-after for andre forespørsler.
- ETag-håndtering: Denne policyen gjelder når ETag-verdier er oppgitt i If-None-Match -headeren for endepunkter som allerede støtter 304 Not Modified .
Handling kreves
Webhooks: Hvis programmet ditt krever oppdateringer i nær sanntid, bruk webhooks i stedet for polling. Webhooks gir en mer effektiv og skalerbar måte å motta oppdateringer på.
Hvis webhooks ikke kan implementeres, bør programmer implementere klientside hurtigbufring for å lagre og gjenbruke API-svar. Når et 304 Not Modified-svar mottas, bør hurtigbufrede data brukes i stedet for å gjøre et nytt API-kall.
Kundene har to måneder etter 16.2.1-utgivelsen til å implementere de anbefalte avspørringsendringene i koden sin. I løpet av dette tidsvinduet vil systemet LOGGE hendelsene for terskel for pollingsintervall.
Etter desember 2025 vil beskyttelsespolicyer for polling bli satt til å HÅNDHEVE feilene vil begynne å utløses for brukere.
Ta kontakt med din CSM hvis du trenger hjelp eller har spørsmål.
Sandkassemiljøet vil aktivere pollingpolicyen til å LOGGE feil 17. september 2025, og settes til å HÅNDHEVE 25. september 2025.
|
Først rapportert: August 2025 |
Fjernet fra gjeldende liste: feb 2026 |
|---|
For å støtte FedRAMP CSP-krav aktiverer vi IPv6-protokollen i Acrobat Sign for Government -miljøet:
- 2001:489a:3102:4::160/124 (IPv6)
- 2001:489a:3102:4::150/124 (IPv6)
|
Først rapportert: September 2025 |
Fjernet fra gjeldende liste: feb 2026 |
|---|
Valideringen av språkinnstillinger har blitt strammet inn ved opprettelse av en avtale via API. Hvis en avtales lokale innstilling ikke er tillatt av kontoens retningslinjer, avviser API-et forespørselen med en tydelig feilmelding. Dette reduserer utilsiktede språkuoverensstemmelser og holder mottakeropplevelser i samsvar med godkjente innstillinger.
Hvem er berørt
- Kontoer som setter avtalens lokale innstilling i API-forespørsler.
- Kontoer som begrenser tilgjengelige lokale innstillinger eller forbyr endringer i lokale innstillinger under sending.
Hva har endret seg
Når innstillingen DISPLAY_LOCALE_INFO_DURING_SEND er aktivert (GLOBAL-nivå), håndhever API-et:
- Avtalens lokale innstilling må være inkludert i brukerens AVAILABLE_LOCALES.
- Hvis ALLOW_LOCALE_SELECTION_DURING_SEND er satt til false, må avtalens lokale innstilling samsvare med brukerens AGREEMENT_LOCALE.
Brudd fører til at POST /agreements mislykkes med: "Lokale innstillinger er enten ugyldige eller mangler."
Vanlig feil og hvordan fikse den
Feil: "Lokale innstillinger er enten ugyldige eller mangler."
- Sjekk de lokale innstillingene som brukes i API-forespørselen (for eksempel en_US).
- Bekreft at de lokale innstillingene vises i AVAILABLE_LOCALES for den kallende brukeren.
- Hvis ALLOW_LOCALE_SELECTION_DURING_SEND er satt til false, sørg for at forespørselens lokale innstillinger samsvarer med AGREEMENT_LOCALE.
- Hvis fleksibilitet på tvers av regioner er nødvendig, aktiver valg av lokale innstillinger ved sending (se Nødvendig handling).
Bakoverkompatibilitet
- Før denne endringen kunne noen forespørsler med uoverensstemmende lokale innstillinger lykkes. Slike forespørsler mislykkes nå med en tydelig feilmelding når valideringene ikke bestås.
- Ingen API-skjemaendringer; valideringsatferden endres kun når DISPLAY_LOCALE_INFO_DURING_SEND er aktivert.
Handling kreves
Administratorer og API-integratorer bør gjøre ett av følgende:
- Juster språkinnstillingen i API-forespørsler med AVAILABLE_LOCALES, og – hvis ALLOW_LOCALE_SELECTION_DURING_SEND er satt til false – match AGREEMENT_LOCALE nøyaktig
- eller -
- Tillat valg av språk ved sending ved å sette:
- ALLOW_LOCALE_SELECTION_DURING_SEND = true
- CAN_CHANGE_UI_LOCALE = true
|
Først rapportert: desember 2025 |
Fjernet fra gjeldende liste: feb 2026 |
|---|
adobe acrobat sign vil rotere adobe acrobat sign SSL-sertifikatet 7. januar 2026.
Handling kreves
- Hvis du har egendefinerte integrasjoner med acrobat sign som bruker REST API-ene, og hvis noen av disse integrasjonene har "festet" den eksisterende offentlige nøkkelen, kreves ingen andre handlinger.
- Hvis du bruker Acrobat Sign sine SSL-Sertifikater for SSO, eller hvis du fester sertifikatet selv (eller bruker andre metoder), kan du finne de nye Acrobat Sign SSL-sertifikatene i Adobe Acrobat Sign systemkrav.
- Hvis SSO-konfigurasjonen støtter flere offentlige sertifikater/kjeder, kan du nå legge til de nye sertifikatene og fjerne det gamle offentlige sertifikatet/kjeden fra konfigurasjonen etter byttet i januar.
- Hvis SSO-en din ikke støtter flere offentlige sertifikater/kjeder, må du synkronisere SSL-byttet ditt med acrobat sign 7. januar 2026.
De nye SSL-sertifikatene vil være hoved 7. januar 2026.
|
Først rapportert: september 2024 – Oppdatert april 2025 |
Gjeldende |
|---|
Webhook 2.0-infrastrukturen er rullet ut til alle kunder, med dette er underskrivervarsler avviklet. Dette fører til at parameteren webhookNotificationApplicableUsers for webhook-nyttelasten ikke lenger gir noen nyttige data. Den fjernes fra alle webhook-nyttelaster.
Sandbox-miljøet blir oppdatert i juni-utgivelsen.
Produksjonsmiljøene blir oppdatert i juli 2025-utgivelsen.
Finner senderens userID og e-postadresse ved hjelp av parameterne initiatingUserId og initiatingUserEmail i varslingsnyttelasten.