Move from Paperwork signing
Use /v1/signing for new product integrations.
It exposes RakeSign documents, templates, consent, webhooks, and administration through one product surface.
POST /v1/sign remains available for existing Paperwork callers.
Its request body, response shape, run URLs, retention rules, and signing behavior remain compatible.
Existing runs continue through their current endpoints.
Compare the workflows
Both paths use the same signing engine. They retain different resource contracts so existing integrations can continue.
Migrate new work
- Create a RakeSign integration key for the target team.
- Select only the required permissions.
- Create or save templates in that team when the integration needs reusable documents.
- Implement the document workflow.
- Register RakeSign webhooks and verify their payloads.
- Route new requests to RakeSign after your integration checks pass.
Keep polling existing Paperwork runs through their original URLs until they finish. Do not resubmit an in-flight document to RakeSign as a migration step. That would create a separate signing request.
Keep existing records
The migration does not import old runs into RakeSign automatically. Existing Paperwork runs do not gain team visibility or RakeSign document IDs. Their retention and access rules remain unchanged.
RakeSign keys cannot call the legacy /v1/sign route.
Keep the existing credential for legacy work until that work finishes.
Recreate delegation scope
Create a saved RakeSign template and request consent for its current revision. Do not copy an old consent status into a new grant. The signer must accept the new revision-bound request.
Read standing delegation before enabling delegated sends.