Agreements
Create and track a document package through draft, delivery, signing and completion.
DEVELOPER CENTER · PREVIEW
Build signing into your workflow.
A practical integration overview for product and engineering teams. Endpoint names and payloads shown here are illustrative until your production specification is issued.
API MODEL
A small surface for a critical workflow.
The eSigner integration model is organised around agreements, recipients and events. Your application creates an agreement, routes it to signers and listens for authoritative status changes.
Recipients
Define signers, reviewers and routing order for each agreement.
Events
Receive webhook notifications when an agreement or recipient changes state.
Developer Preview: The examples below explain the intended integration pattern. They do not constitute a public production API contract. Base URLs, schemas, authentication and availability are confirmed during onboarding.
Quickstart pattern
Use a server-side integration. Never expose credentials in browser or mobile application code.
1. Authenticate
Your onboarding package will provide the current authentication method and environment details. The bearer token below is an illustrative placeholder.
HTTP HEADERILLUSTRATIVE
Authorization: Bearer YOUR_SERVER_TOKEN2. Create an agreement
Send the document reference, recipients and routing settings from your secure backend.
REQUESTILLUSTRATIVE JSON
POST /v1/agreements
{
"title": "Service Agreement",
"document_id": "doc_8R2K",
"recipients": [{
"email": "signer@example.com",
"role": "signer",
"order": 1
}]
}3. Track completion
Persist the returned agreement ID and treat verified webhook events as the source for asynchronous state changes.
Agreement operations
The final production specification may expose a subset or variation of these operations depending on your plan and region.
POST
/v1/agreementsGET
/v1/agreements/{agreement_id}POST
/v1/agreements/{agreement_id}/sendPOST
/v1/agreements/{agreement_id}/cancelWebhook events
Acknowledge valid events quickly, process them idempotently and move longer work to a queue. Verify the signing secret and event timestamp before trusting a payload.
| Event | Meaning | Recommended action |
|---|---|---|
agreement.sent | The invitation flow has started. | Update your internal workflow state. |
recipient.completed | A recipient has completed their assigned action. | Record the actor and completion time. |
agreement.completed | All required actions are complete. | Fetch or link the final record when available. |
agreement.declined | A recipient declined to proceed. | Notify the agreement owner and stop dependent work. |
Errors and retries
Design for safe retries. Supply an idempotency key for create operations when supported, and use exponential backoff for temporary failures.
| Status | Use | Client action |
|---|---|---|
400 | Invalid request | Correct the payload before retrying. |
401 / 403 | Authentication or access failure | Refresh credentials or review scope. |
404 | Resource not found | Confirm the environment and resource ID. |
409 | State conflict | Fetch current state before deciding whether to retry. |
429 | Rate limited | Respect the retry interval and back off. |
5xx | Temporary service issue | Retry safely with backoff and alert after a threshold. |
Request integration access
Production credentials are provided only after commercial and technical review. Tell us your use case, expected volume, markets and preferred launch date.