eContract Developers

Changelog

API versioning policy and change history of the eContract API, including the agent platform release with the MCP server, OAuth 2.1 and free mode.

All notable changes to the eContract API are documented here. We follow Semantic Versioning for API releases.

Breaking Changes Policy

We are committed to API stability. Breaking changes are:

  • Announced at least 30 days in advance via email to all registered developers
  • Versioned — breaking changes require a new major API version
  • Documented — all deprecated endpoints include migration guides

A "breaking change" includes:

  • Removing an endpoint or HTTP method
  • Removing or renaming a request/response field
  • Changing the type of an existing field
  • Adding a new required request parameter
  • Changing authentication or authorization behavior
  • Changing error response codes for existing conditions

Non-breaking changes (added endpoints, new optional fields, new enum values) may be shipped at any time without a version bump.


v1.1.0 — 2026-10 — Agent platform

eContract is now built for AI agents: the whole contract job can be done through the API or the new MCP server. Signing stays human.

Added

  • Remote MCP server at https://api.econtract.online/mcp (Streamable HTTP) with 12 tools: templates, send, status, signing links, reminders, void, signed PDF, audit trail, PDF verification and AI analysis. See MCP server.
  • OAuth 2.1 authorization server: authorization code + PKCE (S256), discovery at /.well-known/oauth-authorization-server, Client ID Metadata Documents, dynamic client registration, refresh token rotation with reuse detection, revocation, iss in authorization responses, resource indicators for the REST API and the MCP server. Users approve apps per workspace and manage them under Connected apps. See OAuth 2.1.
  • POST /contracts/send accepts JSON with files[] (base64 content or an https URL, up to 10 files) and delivery (email, link, both).
  • POST /contracts/{id}/signing-links: signing links for every signer, without sending email.
  • GET /contracts/{id}/document?version=signed|original: the PDF with X-Document-Version and X-Document-Sha256.
  • GET /contracts/{id}/audit-trail: signers, events, hash-chain check and document SHA-256.
  • Idempotency-Key on contract writes (send, create, submit, void, reminders, signing links, add signer, generate from template). See Idempotency.
  • Error envelope on the contract API: { statusCode, error, code, message, details?, requestId } and the X-Request-Id header. See Errors.
  • Webhooks: events contract.created and signer.viewed; payloads gain id (event id) and livemode, and data.contract / data.signer; new headers X-Econtract-Event, X-Econtract-Event-Id, X-Econtract-Delivery, X-Econtract-Timestamp. Webhooks can be managed with API keys and OAuth tokens (webhooks:read, webhooks:write) and in the dashboard under Webhooks.
  • Scope catalogue: templates:delete, files:delete, webhooks:read, webhooks:write, ai:use; signing:write and workflow:write replace signing:create and workflow:execute (the old names keep working).
  • GET /api/v1/openapi.json: the public OpenAPI document.

Changed

  • Free mode: every feature is free with fair-use caps; over a cap the API answers 429 USAGE_LIMIT_REACHED with Retry-After. Billing endpoints answer 410 BILLING_DISABLED. See Limits and pricing.
  • Rate limits per API key or OAuth grant: 60/minute, 1,000/hour, 10,000/day, with X-RateLimit-* headers (X-RateLimit-Reset is in seconds) and 429 RATE_LIMITED.
  • API keys and OAuth tokens act as their user with the role capped at contract_manager, and need both the role permission and the scope. Contracts they create show the real creator.
  • Machine credentials get explicit errors: INSUFFICIENT_SCOPE (with required_scope), MACHINE_NOT_ALLOWED, SCOPE_REQUIRED, HUMAN_ACTION_REQUIRED.
  • API key rotation revokes the old key at once (no grace period).
  • A failed /contracts/send keeps the contract with processingStatus: "failed" instead of deleting it.

Security

  • Signing and declining are refused to API keys and OAuth tokens (403 HUMAN_ACTION_REQUIRED).
  • Webhook and file URLs must resolve to public addresses; the connection is pinned to the checked address and redirects are not followed.

v1.0.0 — 2026-03-22

Initial public release of the eContract API.

Endpoints

  • Auth — POST /auth/login, POST /auth/register, POST /auth/verify-email, GET /auth/me, GET /auth/workspaces, POST /auth/select-workspace
  • Contracts — POST /contracts, GET /contracts, GET /contracts/:id, PUT /contracts/:id, DELETE /contracts/:id, POST /contracts/:id/submit, POST /contracts/:id/void, POST /contracts/send
  • Signers — GET|POST /contracts/:id/signers, DELETE /contracts/:id/signers/:signerId
  • Templates — GET|POST /contract-templates, GET|PUT|DELETE /contract-templates/:id, POST /contract-templates/:id/generate
  • Webhooks (admin session) — POST /webhooks, GET /webhooks, PATCH|DELETE /webhooks/:id, POST /webhooks/:id/test
  • API Keys (admin session) — POST|GET /workspaces/:workspaceId/api-keys, POST /api-keys/:id/revoke, POST /api-keys/:id/rotate

Authentication

  • API key authentication via Authorization: Bearer <key>
  • JWT bearer tokens for session-based access
  • OTP verification for signer identity

Rate Limits

  • Free: 100 requests/day
  • Personal: 1,000 requests/day
  • Business: 10,000 requests/day

Contract Lifecycle

Contracts follow the status flow: draft → pending → in_signing → completed (or voided / expired).

On this page