SignNow User Management API Guide

Auth method: OAuth 2.0 (password grant and authorization code grant; Basic Auth used only for token issuance)

Setup steps

1. Register an application in the SignNow Developer portal to obtain a client_id and client_secret.
2. Base64-encode 'client_id:client_secret' and pass as 'Authorization: Basic ' header to POST /oauth2/token.
3. Supply grant_type=password with username and password (or grant_type=authorization_code for code flow) to receive an access_token and refresh_token.
4. Include 'Authorization: Bearer ' on all subsequent API requests.
5. Use the refresh_token with grant_type=refresh_token to obtain a new access_token before expiry.

Required scopes

Create User

• Method: POST
• URL: https://api.signnow.com/user
• Watch out for: Requires a valid Bearer token from an account with admin/org privileges to create users under a team.

Request example

POST /user
Authorization: Bearer <token>
Content-Type: application/json
{
  "email": "user@example.com",
  "password": "SecurePass1!",
  "first_name": "Jane",
  "last_name": "Doe"
}

Response example

{
  "id": "abc123def456",
  "email": "user@example.com",
  "first_name": "Jane",
  "last_name": "Doe",
  "created": 1700000000
}

Get Current User

• Method: GET
• URL: https://api.signnow.com/user
• Watch out for: Returns the user associated with the Bearer token, not an arbitrary user by ID.

Request example

GET /user
Authorization: Bearer <token>

Response example

{
  "id": "abc123def456",
  "email": "user@example.com",
  "first_name": "Jane",
  "last_name": "Doe",
  "active": true,
  "created": 1700000000
}

Update User

• Method: PUT
• URL: https://api.signnow.com/user
• Watch out for: Updates the authenticated user only; no endpoint to update an arbitrary user by ID via admin token is documented.

Request example

PUT /user
Authorization: Bearer <token>
Content-Type: application/json
{
  "first_name": "Janet",
  "last_name": "Smith"
}

Response example

{
  "id": "abc123def456",
  "first_name": "Janet",
  "last_name": "Smith",
  "updated": 1700001000
}

Issue OAuth Token (Password Grant)

• Method: POST
• URL: https://api.signnow.com/oauth2/token
• Watch out for: Basic Auth header must use base64-encoded 'client_id:client_secret'. Scope '*' is required for full access.

Request example

POST /oauth2/token
Authorization: Basic <base64(client_id:client_secret)>
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=user@example.com&password=SecurePass1!&scope=*

Response example

{
  "access_token": "eyJ...",
  "token_type": "bearer",
  "expires_in": 3600,
  "refresh_token": "def50200..."
}

Refresh OAuth Token

• Method: POST
• URL: https://api.signnow.com/oauth2/token
• Watch out for: Refresh tokens are single-use; store the new refresh_token returned in each response.

Request example

POST /oauth2/token
Authorization: Basic <base64(client_id:client_secret)>
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=def50200...&scope=*

Response example

{
  "access_token": "eyJ...",
  "token_type": "bearer",
  "expires_in": 3600,
  "refresh_token": "ghi60300..."
}

Get Organization Users (Team Members)

• Method: GET
• URL: https://api.signnow.com/api/v2/organizations/{organization_id}/users
• Watch out for: Requires an admin-level token for the organization. organization_id must be retrieved separately.

Request example

GET /api/v2/organizations/org123/users?per_page=25&page=1
Authorization: Bearer <token>

Response example

{
  "data": [
    {"id": "abc123", "email": "user@example.com", "first_name": "Jane", "last_name": "Doe"}
  ],
  "meta": {"total": 50, "page": 1, "per_page": 25}
}

Send Document Invite (user-facing action)

• Method: POST
• URL: https://api.signnow.com/document/{document_id}/invite
• Watch out for: Not strictly a user-management endpoint but commonly used in user provisioning workflows to onboard signers.

Request example

POST /document/doc456/invite
Authorization: Bearer <token>
Content-Type: application/json
{
  "to": [{"email": "signer@example.com", "role": "Signer", "order": 1}],
  "from": "sender@example.com"
}

Response example

{
  "status": "success"
}

Revoke OAuth Token

• Method: POST
• URL: https://api.signnow.com/oauth2/token/{access_token}
• Watch out for: Uses DELETE method despite the /oauth2/token path. Revoking a token immediately invalidates all API calls using it.

Request example

DELETE /oauth2/token/eyJ...
Authorization: Bearer <token>

Response example

{
  "result": "Token has been revoked"
}

• Rate limits: SignNow does not publicly document specific rate limit thresholds or per-plan tiers in its developer docs as of the research date.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No explicit rate limit values, headers, or Retry-After behavior documented in official sources. API plans start at $84/mo; higher tiers may have higher limits but specifics are not published.

• Pagination method: offset

• Default page size: 25

• Max page size: 100

• Pagination pointer: per_page / page

• Webhooks available: Yes

• Webhook notes: SignNow supports event subscriptions (webhooks) via the /api/v2/events endpoint. Callbacks are sent as HTTP POST to a configured URL when events occur.

• Alternative event strategy: Polling the /user or /document endpoints as a fallback if webhook delivery is unreliable.

• Webhook events: document.create, document.update, document.delete, document.complete, invite.create, invite.update, invite.complete, invite.decline, user.create, user.update

• SCIM available: No
• SCIM version: Not documented
• Plan required: Enterprise
• Endpoint: Not documented

Limitations:

• No native SCIM 2.0 endpoint is documented in official SignNow developer docs.
• SCIM-based provisioning for Okta and Entra ID may be available via IdP-specific connectors at the Enterprise tier, but no vendor-hosted SCIM base URL is publicly documented.
• User provisioning via IdP connectors (Okta, Entra) requires Enterprise plan per context data.

Three integration scenarios are well-supported by the documented API surface.

First, provisioning a new team member: authenticate as org admin via POST /oauth2/token (password grant), create the account via POST /user, retrieve the organization_id via GET /api/v2/organizations, then confirm membership via GET /api/v2/organizations/{organization_id}/users.

Note that POST /user creates a standalone account - associating it with a specific org team may require additional steps not fully documented publicly.

Second, maintaining a long-running integration with token refresh: store the refresh_token at initial auth, POST /oauth2/token with grant_type=refresh_token before or on a 401, and replace both tokens in storage immediately.

Refresh tokens are single-use;

concurrent refresh attempts from two processes will break the token chain and force full re-authentication.

Third, event-driven provisioning via webhooks: register events at POST /api/v2/events with a callback URL, scope to entity_id where needed, and handle retries idempotently since delivery guarantees are not specified.

Provision a new team member via API

1. Authenticate as org admin: POST /oauth2/token with grant_type=password and admin credentials to get access_token.
2. Create the user account: POST /user with email, password, first_name, last_name in the request body.
3. Retrieve the organization_id: GET /api/v2/organizations to find the org the admin manages.
4. Verify the user appears in the org: GET /api/v2/organizations/{organization_id}/users and confirm the new user is listed.

Watch out for: User creation via POST /user creates a standalone account; associating the user with a specific organization/team may require additional org-membership steps not fully documented in public docs.

Refresh an expiring OAuth token in a long-running integration

1. Store the refresh_token securely at initial authentication.
2. Before or upon receiving a 401 response, POST /oauth2/token with grant_type=refresh_token and the stored refresh_token.
3. Replace both the stored access_token and refresh_token with the values returned in the response.
4. Retry the original failed request with the new access_token.

Watch out for: Refresh tokens are single-use. If two processes attempt to refresh simultaneously, one will fail and the token chain will break, requiring re-authentication with username/password.

Subscribe to user and document events via webhooks

1. Authenticate and obtain a Bearer token with admin scope.
2. Register a webhook: POST /api/v2/events with event name (e.g., 'user.create'), callback URL, and entity_id if scoping to a specific document or user.
3. Validate incoming webhook payloads at your callback URL by checking the event type and entity_id fields.
4. Handle retries: if your endpoint returns non-2xx, SignNow will retry delivery; ensure idempotent processing.

Watch out for: Webhook reliability and retry behavior are not fully specified in public docs; implement idempotency keys on your receiver to avoid duplicate processing.

The most consequential caveat in the SignNow API is the absence of a true admin-scoped user-update endpoint: PUT /user modifies only the authenticated user, and no documented endpoint allows an admin token to update an arbitrary user by ID.

This limits automated offboarding - deactivating or modifying a specific user's account programmatically is not straightforwardly supported by the public API surface. SCIM 2.0 is not natively available;

IdP-based provisioning via Okta or Entra ID connectors exists at the Enterprise tier but uses connector-specific flows rather than a standard SCIM base URL, which means integrations built against a generic SCIM client will not work out of the box.

Rate limits are entirely undocumented - no thresholds, no rate-limit headers, no Retry-After behavior - so any production integration must implement exponential backoff on 429 responses defensively.

Finally, the v1/v2 API split is a maintenance risk: some user-management operations are only available on v2, and the two surfaces are not fully consistent in their response schemas.