GetAccept User Management API Guide

Auth method: OAuth 2.0 (Bearer token) or API key via Authorization header

Setup steps

1. Log in to GetAccept and navigate to Settings > Integrations > API.
2. Generate an API key or register an OAuth 2.0 application to obtain client_id and client_secret.
3. For OAuth 2.0: POST to https://api.getaccept.com/v1/oauth/token with grant_type=client_credentials, client_id, and client_secret to receive an access_token.
4. Include the token in all requests as: Authorization: Bearer .
5. For API key auth: include as Authorization: Bearer directly.

Required scopes

List users

• Method: GET
• URL: https://api.getaccept.com/v1/users
• Watch out for: Returns only users within the authenticated account's organization scope.

Request example

GET /v1/users?page=1&limit=25
Authorization: Bearer <token>

Response example

{
  "users": [
    {"id": "abc123", "email": "user@example.com",
     "first_name": "Jane", "last_name": "Doe",
     "status": "active", "role": "member"}
  ],
  "total": 50, "page": 1
}

Get user by ID

• Method: GET
• URL: https://api.getaccept.com/v1/users/{id}
• Watch out for: Returns 404 if user ID does not exist in the organization.

Request example

GET /v1/users/abc123
Authorization: Bearer <token>

Response example

{
  "id": "abc123",
  "email": "user@example.com",
  "first_name": "Jane",
  "last_name": "Doe",
  "role": "member",
  "status": "active"
}

Create user

• Method: POST
• URL: https://api.getaccept.com/v1/users
• Watch out for: An invitation email is sent to the new user upon creation. Duplicate email returns 409.

Request example

POST /v1/users
Authorization: Bearer <token>
Content-Type: application/json

{"email":"new@example.com","first_name":"John","last_name":"Smith","role":"member"}

Response example

{
  "id": "xyz789",
  "email": "new@example.com",
  "first_name": "John",
  "last_name": "Smith",
  "status": "active"
}

Update user

• Method: PATCH
• URL: https://api.getaccept.com/v1/users/{id}
• Watch out for: Only include fields to be changed; omitted fields are not modified.

Request example

PATCH /v1/users/xyz789
Authorization: Bearer <token>
Content-Type: application/json

{"title":"Sales Manager","team_id":"team001"}

Response example

{
  "id": "xyz789",
  "title": "Sales Manager",
  "team_id": "team001",
  "updated_at": "2025-06-01T10:00:00Z"
}

Deactivate/delete user

• Method: DELETE
• URL: https://api.getaccept.com/v1/users/{id}
• Watch out for: Behavior may be soft-delete (status set to inactive) rather than permanent deletion. Verify with GetAccept support for data retention implications.

Request example

DELETE /v1/users/xyz789
Authorization: Bearer <token>

Response example

{
  "success": true,
  "message": "User deactivated"
}

List teams

• Method: GET
• URL: https://api.getaccept.com/v1/teams
• Watch out for: Team IDs are required when assigning users to teams via the users endpoint.

Request example

GET /v1/teams
Authorization: Bearer <token>

Response example

{
  "teams": [
    {"id": "team001", "name": "Sales EMEA",
     "member_count": 12}
  ]
}

Get current authenticated user

• Method: GET
• URL: https://api.getaccept.com/v1/users/me
• Watch out for: Useful for validating token scope and confirming the acting user identity.

Request example

GET /v1/users/me
Authorization: Bearer <token>

Response example

{
  "id": "abc123",
  "email": "admin@example.com",
  "role": "admin",
  "status": "active"
}

• Rate limits: GetAccept enforces rate limits on API requests; exact published limits are not fully documented publicly.
• Rate-limit headers: Yes
• Retry-After header: No
• Rate-limit notes: Rate limit headers (X-RateLimit-Limit, X-RateLimit-Remaining) are returned in responses. Specific numeric limits are not publicly documented; contact GetAccept support for Enterprise quotas.
• Pagination method: offset
• Default page size: 25
• Max page size: 100
• Pagination pointer: page / limit

• Webhooks available: Yes
• Webhook notes: GetAccept supports webhooks for document and deal lifecycle events. User-specific webhook events (e.g., user created/deactivated) are not explicitly documented in public references.
• Alternative event strategy: Poll GET /v1/users on a schedule to detect user changes if user-lifecycle webhooks are not available.
• Webhook events: document.sent, document.viewed, document.signed, document.completed, document.declined, deal.created, deal.updated

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: https://api.getaccept.com/scim/v2

• Supported operations: GET /Users, GET /Users/{id}, POST /Users, PUT /Users/{id}, PATCH /Users/{id}, DELETE /Users/{id}, GET /Groups, POST /Groups, PATCH /Groups/{id}, DELETE /Groups/{id}

Limitations:

• Requires Enterprise plan
• SSO (SAML) must be configured as a prerequisite before enabling SCIM
• Supported IdPs: Okta, Microsoft Entra ID (Azure AD); Google Workspace and OneLogin not officially supported
• SCIM token is generated from GetAccept admin settings and used as Bearer token in IdP SCIM configuration
• Group sync maps to GetAccept Teams; team names must match exactly or be created in GetAccept first

For IdP-driven provisioning, the SCIM 2. 0 path is the correct integration surface.

SAML SSO must be fully configured in GetAccept before SCIM can be enabled - activating SCIM without an active SSO configuration will fail. Supported IdPs are Okta and Microsoft Entra ID (Azure AD); Google Workspace and OneLogin are not officially supported.

Group sync maps to GetAccept Teams, and team names must match exactly or be pre-created in GetAccept before the IdP pushes group assignments.

For user auditing and identity graph reconciliation, the REST API is the appropriate path. Call GET /v1/users with limit=100, paginate until the returned count falls below the limit, and filter on status == 'active' to build a current roster. The user object surfaces id, email, role, status, team_id, created_at, and updated_at - sufficient to join against an external identity graph for cross-system access reviews. Note that created_at and updated_at are available, but a last-login timestamp is not exposed via the API, mirroring the gap in the admin UI.

For deprovisioning via REST, retrieve the user's id via GET /v1/users filtered by email, then call DELETE /v1/users/{id}. The DELETE operation may be a soft-delete (status set to inactive) rather than permanent removal - confirm data retention and license release behavior with GetAccept support before relying on this in an automated offboarding workflow. If using SCIM, deprovision at the IdP level; the IdP will push DELETE /Users/{id} to the SCIM endpoint automatically.

Provision a new employee via SCIM (Okta)

1. Ensure Enterprise plan is active and SAML SSO is configured in GetAccept Settings > Security.
2. In GetAccept admin, navigate to Settings > Integrations > SCIM and generate a SCIM Bearer token.
3. In Okta, add the GetAccept SCIM app, set Base URL to https://api.getaccept.com/scim/v2, and paste the Bearer token.
4. Assign the Okta user to the GetAccept app; Okta pushes a POST /Users to GetAccept SCIM endpoint.
5. Verify the user appears in GetAccept with correct role and team assignment.

Watch out for: If the user's email already exists in GetAccept as an unmanaged account, SCIM may conflict. Pre-clean duplicate accounts before enabling SCIM.

Bulk-list and audit active users via REST API

1. Obtain a Bearer token via POST /v1/oauth/token with client_credentials.
2. Call GET /v1/users?page=1&limit=100 and collect results.
3. Iterate pages (increment page param) until returned user count < limit.
4. Filter results where status == 'active' for the active user roster.
5. Cross-reference with HR system to identify accounts to deactivate.

Watch out for: Max page size is 100; large organizations must paginate fully. Token expiry mid-loop requires refresh handling.

Deactivate a departed employee

1. Retrieve the user's GetAccept ID via GET /v1/users?email=departed@example.com or list endpoint.
2. Call DELETE /v1/users/{id} with the user's ID.
3. Confirm response returns success:true.
4. If using SCIM, deprovision the user in the IdP; the IdP will send DELETE /Users/{id} to GetAccept automatically.

Watch out for: REST API DELETE may soft-deactivate rather than permanently remove the user. Documents owned by the user remain; reassign ownership before deactivation if needed.

The primary integration trap is conflating the REST API and SCIM API as interchangeable. Creating a user via POST /v1/users sends an invitation email automatically and does not integrate with IdP lifecycle management. If onboarding flow is controlled by an IdP, use SCIM exclusively for provisioning to avoid duplicate accounts and unmanaged invitation emails.

A second trap is assuming the DELETE endpoint performs hard deletion. The operation likely soft-deactivates the user record; documents owned by that user are retained and not reassigned.

Any automation that assumes license reclamation or data removal on DELETE must be validated against actual API behavior - the public documentation does not guarantee permanent deletion, and GDPR removal requests require contacting GetAccept support directly.

Role values are case-sensitive (admin, member in lowercase); incorrect casing will cause create or update operations to fail silently or return errors. User-lifecycle webhook events (user created, user deactivated) are not documented in public references - poll GET /v1/users on a schedule if real-time user-change detection is required and SCIM is not in use.