Skapa inbäddade e-signaturer och dokumentupplevelser
Lär dig hur du använder Acrobat Sign API:er för att bädda in e-signaturer och dokumentupplevelser i dina webbplattformar och system för innehållshantering. Den här praktiska självstudiekursen består av fyra delar.
Del 1: Vad du behöver
I del 1 lär du dig hur du kommer igång med allt du behöver för delarna 2-4. Vi börjar med att få API-inloggningsuppgifter.
-
Python 3.x
- Mac - Homebrew
- Linux - inbyggt installationsprogram
- Windows - Chocolatey
- All - https://www.python.org/downloads/
Del 2: Låg/ingen kod - kraften i webbformulär
I del 2 utforskar du alternativet låg/ingen kod för att använda webbformulär. Det är alltid en bra idé att se om du kan undvika att skriva kod i början.
-
Kom åt Acrobat Sign med ditt utvecklarkonto.
-
Markera Publish ett webbformulär på startsidan.
-
Skapa ett avtal.
-
Bädda in ditt avtal på en platt HTML-sida.
-
Experimentera med att lägga till frågeparametrar dynamiskt.
Del 3: Skicka avtal med ett formulär och sammanfoga data
I del 3 skapar du avtal dynamiskt.
Först måste du upprätta åtkomst. Med Acrobat Sign finns det två sätt att ansluta via API. OAuth-tokens och integrationsnycklar. Om du inte har ett mycket specifikt skäl till att använda OAuth med ditt program bör du utforska Integreringsnycklar först.
-
Välj Integreringsnyckel på menyn API-information på fliken Konto i Acrobat Sign.
Nu när du har åtkomst och kan interagera med API:et, se vad du kan göra med API:et.
-
Gå till Acrobat Sign REST API Version 6-metoderna.
-
Använd token som ett bärarvärde.
När du vill skicka ditt första avtal är det bäst att förstå hur du använder API:et.
- Skapa ett övergående dokument och skicka det.
| note note |
|---|
| NOTE |
| JSON-baserade förfrågningsanrop har alternativen "Model" och "Minimal Model Schema". Detta ger specifikationer och en lägsta nyttolast uppsättning. |
När du har skickat ett avtal för första gången är du redo att lägga till logiken. Det är alltid en bra idé att etablera vissa hjälpfunktioner för att minimera upprepning. Här är några exempel:
Validering
Rubriker/autentisering
Bas-URI
Var medveten om var Övergående dokument hamnar i signeringsekosystemets stora schema.
Övergående -> Avtal
Övergående -> Mall -> Avtal
Övergående -> Widget -> Avtal
I det här exemplet används en mall som dokumentkälla. Detta är vanligtvis det bästa sättet om du inte har en solid anledning att dynamiskt generera dokument för signatur (t.ex. äldre kod eller dokumentgenerering).
Koden är ganska enkel. Den använder ett biblioteksdokument (mall) för dokumentkällan. Den första och andra undertecknaren tilldelas dynamiskt. Tillståndet IN_PROCESS innebär att dokumentet skickas omedelbart. Dessutom utnyttjas mergeFieldInfo för att fylla i fält dynamiskt.
Del 4: Bädda in signeringsupplevelse, omdirigeringar och annat
I många scenarier kanske du vill tillåta att den utlösande deltagaren omedelbart signerar ett avtal. Detta är användbart för kundvända applikationer och kiosker.
Om du inte vill att det första e-postmeddelandet ska utlösas är det ett enkelt sätt att hantera beteendet genom att ändra API-anropet.
Så här styr du omdirigering efter signering:
När du har uppdaterat processen för att skapa avtal genereras signerings-URL:en i det sista steget. Det här anropet är också ganska enkelt och genererar en URL som en signerare kan använda för att komma åt sin del av signeringsprocessen.
| note note |
|---|
| NOTE |
| Observera att anropet för att skapa avtal är tekniskt asynkront. Det innebär att ett anrop till ett "POST"-avtal kan göras, men avtalet är inte klart än. Det bästa sättet är att skapa en upprepningsslinga. Använd ett nytt försök eller något som är det bästa tillvägagångssättet för din miljö. |
När allt är sammansatt är lösningen ganska enkel. Du skapar ett avtal och sedan en signerings-URL som signeraren kan klicka på och påbörja signeringsritualen.
Ytterligare ämnen
-
Webhook-händelser
-
Återaktivera e-postmeddelanden om förfrågningar (med händelser)
-
Anpassade påminnelser
-
Med det första skapandet
-
Eller lägg till en pågående
-