Skip to navigation

RakeSign API

Build signature workflows on the same resources your team uses in RakeSign.
View as Markdown

The RakeSign API uses this base URL:

https://api.cloudraker.com/v1/signing

Use it to prepare documents, manage templates, send signature requests, and track results. The API also exposes contacts, signing groups, branding, forms, bulk jobs, reports, and standing delegation.

Start an integration

  1. Ask an organization administrator to create a scoped key in RakeSign → Developers.
  2. Choose the team whose shared resources the integration needs.
  3. Follow the document workflow.
  4. Subscribe to webhooks to track delivery and signing events.

Send the key as a bearer credential from your server:

curl 'https://api.cloudraker.com/v1/signing/documents?pageSize=50' \
  -H "Authorization: Bearer $RAKESIGN_API_KEY"

Document lists return items and nextCursor. Send the returned cursor with your next list request. Individual resource operations return the resource directly.

One product surface

API documents appear in RakeSign under the integration’s team. The app and API use the same versioned drafts, templates, access rules, signature engine, and audit records.

An integration has a stable identity separate from its credential. Rotating a key preserves document ownership and scheduled work references. Permission changes, expiry, and revocation apply when requests or scheduled work run.

Errors and retries

Errors use the /v1 error envelope with code, message, retryable, and requestId. Branch on HTTP status and code. Do not parse the human-readable message.

StatusAction
400 or 422Correct the request or unsupported signing configuration.
401Check the bearer credential.
403Check permissions, team management, expiry, or revocation.
404Check the ID and access. Inaccessible resources also return this status.
409Refresh the resource and resolve its version or state conflict.
429Wait for Retry-After before retrying.
503Retry with backoff after checking whether the operation already completed.

The API shares the organization’s /v1 request budget. See rate limits for the response headers and backoff guidance.

Use documented idempotency and version controls for each operation. Do not assume every mutation supports Idempotency-Key.

Existing Paperwork integrations

POST /v1/sign remains available with its existing request and run response contract. Use the migration guide to move new work to RakeSign without changing existing runs.