API for Adobe Acrobat Sign – vanlige spørsmål

1. Logg inn på Acrobat Sign.
2. Naviger til Acrobat Sign API > REST API dokumentasjon.
3. Velg versjon 5.
4. Under metoden post /users bruker du forespørselskoden nevnt under
   UserCreationInfo-metoden
   {
   "email": "email@email.com",
   "firstName": "AA",
   "lastName": "AB",
   "password": "12******rte"
   }

Acrobat Sign-kontoer som bruker Admin Console (Adobe One) til å administrere brukerrettigheter, kan ikke bruke Acrobat Sign API til å opprette brukere eller administrere eksisterende brukere.

Adobe One Admin Console bruker en annen API enn Acrobat Sign-API. Se disse artiklene for mer informasjon:

• https://helpx.adobe.com/no/enterprise/help/users.html
• https://developer.adobe.com/umapi/

Hente gruppe-ID:

Slette gruppe:

Generere et transient dokument

Generere en avtale ved hjelp av transientdokumentet

Det følgende er trinnene for å legge til filer i FileInfo Parameter:

I POST /agreements-kallet kan du for signatureflow-parameteren sende SENDER_SIGNS_FIRST- eller SENDER_SIGNS_LAST-verdien for å legge til avsenderen som henholdsvis første eller siste underskriver.

Her er et eksempel på kallet i JSON-format:

{

  "documentCreationInfo": {

    "fileInfos": [

      {        "transientDocumentId":"3AAABLblqZ-yourIDGoesHere"

      }

    ],

    "name": "Test",

    "recipientSetInfos": [

      {

        "recipientSetMemberInfos": [

          {

            "email": "test@email.com"

          }

        ],

        "recipientSetRole": "SIGNER"

      }

    ],

    "signatureType": "ESIGN",

    "signatureFlow": "SENDER_SIGNS_FIRST"

  }

}

For funksjonen Send på vegne aktiverer du Avansert kontodeling for kontoen, slik at brukere kan gi sendetillatelser til andre brukere mens de deler kontoen sin. For Avansert deling, se Enabling Advanced Account Sharing.

Når brukerdeling er aktivert, følger du disse trinnene for å sende på vegne av:

Generere et transient dokument:

Generere en avtale ved hjelp av Transient-dokumentet:

Følgende parametere kan du sende i koden for å angi et åpningspassord:

Gjør følgende for å opprette en avtale ved hjelp av API med statusen "AUTHORING":

Gå til Post /agreements og opprett tilgangstoken med de nødvendige omfangene.

Bruk følgende forespørselskode:

V6 har et sett med authoring-API-er for oppretting av avtale. I v5 konsumeres formFields direkte i API-et POST /agreements. I v6 kan imidlertid brukeren opprette en avtale i AUTHORING-status (state = AUTHORING) gjennom v6 POST /agreements og bruke PUT /agreements/ID/formFields senere for å legge til skjemafelt i dokumentene til denne avtalen.

Dette er trinnene:

Bruk POST /agreements til å opprette en avtale. Sender den ut til signering, og returnerer agreementID-en i svaret til klienten. Nedenfor er JSON-formatet for å sende avtale ved bruk av telefongodkjenningsmetode.

Du kan flette dataene direkte i skjemafeltene ved å bruke følgende metoder:

• Med en bibliotekmal:
  
  Hvis du bruker en bibliotekmal-ID under FileInfo-parameteren, må du sørge for å oppgi nøyaktig feltnavn og tilhørende data under delen nedenfor:

• Bruk av tekstkoder i et dokument lastet opp som et transient dokument:
  
  Hvis du laster opp et dokument som har tekstkoder lagt til som et transient dokument, må du sørge for å oppgi det nøyaktige feltnavnet og tilhørende data under delen nedenfor: 

Hvordan sender jeg en avtale ved hjelp av API som har forhåndsutfylte verdier for de spesifikke skjemafeltene (mergefield)?

Forutsetningen for dette kallet er å først fullføre trinnet "Transient Upload" og få en "transientDocumentId" (ved å bruke: secure.na1.echosign.com/public/docs/restapi/v5#!/transientDocuments/createTransientDocument) som skal brukes her.

• Dette kallet inkluderer "mergeFieldInfo"-delen der standardverdier for spesifikke skjemafelt er gitt.
• Dette forhåndsutfyller dataene fra et annet system i API-kallet.
• Disse feltene i avtalen er enten redigerbare eller skrivebeskyttede.

Forutsetninger:

1. Transient dokument-ID
2. Feltnavn og tilhørende verdier

Eksempel på forespørselskall:

Ved kjøring av metoden "post /megaSigns/{megaSignId}/views", vises feilmeldingen "Requested view is not available for the resource in the current state."

Feilen vises hvis den angitte navneparameterverdien er ugyldig i nedenstående forespørselskode:

{
  "name": " "
}

Hvis for eksempel MegaSign-avtalen allerede er "IN_PROCESS", vil verdien "AUTHORING" gi nevnte feilmelding. Forsikre deg om at den oppgitte verdien du får er i samsvar med gjeldende status for avtalen.

Ved kjøring av metoden "put /megaSigns/{megaSignId}/state", vises feilmeldingen "No value provided for MegaSign cancellation info."

Feilen skyldes at forespørselskoden mangler parameteren: 

 "megaSignCancellationInfo": {
    "comment": "",
    "notifyOthers": false
  }

I stedet for å bruke "Minimal Schema", klikker du på "Complete Model Schema" og oppgir hele forespørselskoden for å kjøre API-kallet. 

For å endre statusen for MegaSign-avtalen bruker du put /megaSigns/{megaSignId}/state og utfører følgende trinn:

1. Gå til REST API-dokumentasjon for V6 og velg metoden  
   put /megaSigns/{megaSignId}/state.
2. Oppgi Authorization-verdi samt If-Match og megasignID.
   • For å hente megasignID bruker du get /megaSigns
   • For å hente If-Match bruker du get /megaSigns/{megaSignId} og lokaliserer "Etag" under Header
3. {
     "state": "CANCELED",
     "megaSignCancellationInfo": {
      "comment": "cancel",
      "notifyOthers": false
     }
   } 

For å lykkes med å registrere en webhook svarer webhook-URL-en på denne bekreftelsesforespørselen med en 2XX-svarkode, og kan dessuten sende tilbake samme klient-ID-verdi på en av følgende to måter:

1. I et svarhode X-AdobeSign-ClientId. Det er det samme hodet som sendes i forespørselen, og blir gjentatt i svaret.
2. I JSON-svarteksten med nøkkelen X-AdobeSign-ClientId og tilhørende verdi den samme klient-ID-en som sendes i forespørselen.

Acrobat Sign mottar 2xx-responsen med X-AdobeSign-ClientId. Brukeren kan sjekke om det er konfigurert riktig i webhook eller ikke.

Webhook-URLen reagerer ikke i henhold til forventet virkemåte. For hver POST-varsling som Acrobat Sign sender, svarer nettadressen med 2XX-statuskode og gjengir klient-ID-en som ble sendt i forespørselshoder (X-AdobeSign-ClientId) tilbake i responshoder. 

For fullstendig informasjon, se følgende lenke:
https://developer.adobe.com/acrobat-sign/docs/overview/developer_guide/#!adobedocs/adobe-sign/master/webhooks/webhook_events.md

Når nettadressen ikke klarer å følge denne protokollen, anser Acrobat Sign at den ikke bekreftet forespørselen og forsøker å sende på nytt i henhold til den pålitelige retningslinjen.

Hvis webhooken ikke svarer, og enten maksimumstiden før nytt forsøk eller maksimumsintervallet for nye forsøk overskrides, deaktiveres webhooken.

  Twitter™- og Facebook-innlegg dekkes ikke under vilkårene for Creative Co

For å endre dokumentet som allerede er sendt ut for signatur bruker du metoden PUT /agreements/{agreementId} som du kan oppdatere en eksisterende avtale med. Oppgi transient ID sammen med agreement ID i følgende forespørselskode:

Det følgende er instruksjoner for å oppdatere statusen fra "AUTHORING" til "IN_PROCESS" ved hjelp av Put /agreements/{agreementId}/state:

Nei.

Det er ingen metode i nåværende REST API for å laste opp en signert kopi.

Avsenderen må laste opp den signerte kopien fra Behandle-siden.

DELETE /agreements/ID ble brukt til å skjule en avtale fra administrasjonssiden.

Adobe har en ny API PUT /agreements/ID/me/visibility for å kontrollere synligheten til en avtale (i GET /agreements). I tillegg til funksjonaliteten som tilbys av DELETE /agreements/ID, tillater det nye synlighetsendepunktet også en bruker å reversere "skjul" -operasjonen, det vil si gjøre avtalen synlig igjen. 

Du kan også følge de detaljerte trinnene nedenfor:

1. Gå til metoden get /agreements og hent agreement ID.
2. Klikk på put /agreements/{agreementId}/me/visibility og oppgi forespørselen nedenfor som eksempel:
   {
     "visibility": "HIDE"
   }
   Agreement ID er bare skjult fra get /libraryDocuments, den er fremdeles synlig på Behandle-fanen i brukergrensesnittet.

Du får følgende svar hvis DELETE/agreements-operasjonen ikke er aktivert:

 "code": "DYNAMIC_DOCUMENT_EXPIRATION_NOT_ENABLED",

  "message": "The operation requires some account settings to be enabled. Ta kontakt med Acrobat Sign-teamet for å aktivere innstillingene."

Hvordan laste ned signert dokument sammen med revisjonsrapport og støttedokument gjennom Acrobat Sign REST API i stedet for å gjøre et separat kall for å laste ned revisjonsrapport ved å bruke følgende metode.

GET /agreements/{agreementId}/auditTrail

For å laste ned mange dokumenter er bare dokumenteksportverktøy tilgjengelig, og med API kan du bare laste ned ett og ett dokument. Det følgende er API-metoden for det samme:

https://secure.na1.adobesign.com/public/docs/restapi/v5#!/agreements/getCombinedDocument

Adobe har det nye API-et PUT/libraryDocuments/ID/me/visibility for å kontrollere synligheten av en avtale (i GET /agreements). I tillegg til funksjonaliteten som tilbys av DELETE /agreements/ID, lar det nye synlighet-endepunktet også en bruker reversere 'skjul'-operasjonen, det vil si gjøre avtalen synlig igjen.

Du kan følge de detaljerte trinnene nedenfor:

1. Gå til metoden get /libraryDocuments og hent agreement ID.
2. Klikk på put /libraryDocuments/{libraryDocumentId}/me/visibility og oppgi forespørselen nedenfor som eksempel:
   {
     "visibility": "HIDE"
   }
   Bibliotek-ID er bare skjult fra get /libraryDocuments, den er fremdeles synlig på Behandle-fanen i brukergrensesnittet.

Generere en libraryDocumentID

Slette bibliotekmaler