Veracode User Management API Guide

Auth method: HMAC SHA-256 (Veracode API credentials – API ID + API Secret Key signed per request)

Setup steps

1. Log in to the Veracode Platform and navigate to your user profile.
2. Generate API credentials (API ID and API Secret Key) under 'API Credentials'.
3. Store the API ID and Secret Key securely; the secret is shown only once.
4. For each request, compute an HMAC SHA-256 Authorization header using the documented signing algorithm (nonce, timestamp, URL, method).
5. Pass the resulting 'Authorization: VERACODE-HMAC-SHA-256 ...' header with every API call.
6. Optionally use the official Veracode API signing libraries (Python, Java, etc.) to automate header generation.

Required scopes

List users

• Method: GET
• URL: https://api.veracode.com/api/authn/v2/users
• Watch out for: Returns HAL+JSON. Iterate pages using the 'page' and 'size' query params; check total_pages to detect end of results.

Request example

GET /api/authn/v2/users?page=0&size=50
Authorization: VERACODE-HMAC-SHA-256 ...

Response example

{
  "_embedded": {
    "users": [{"user_id":"uuid","user_name":"alice@example.com","first_name":"Alice"}]
  },
  "page": {"size":50,"total_elements":120,"total_pages":3,"number":0}
}

Get user by ID

• Method: GET
• URL: https://api.veracode.com/api/authn/v2/users/{userId}
• Watch out for: Requires the caller to have Administrator or Security Lead role.

Request example

GET /api/authn/v2/users/a1b2c3d4-...
Authorization: VERACODE-HMAC-SHA-256 ...

Response example

{
  "user_id": "a1b2c3d4-...",
  "user_name": "alice@example.com",
  "first_name": "Alice",
  "last_name": "Smith",
  "active": true,
  "roles": [{"role_name":"Security Lead"}]
}

Create user

• Method: POST
• URL: https://api.veracode.com/api/authn/v2/users
• Watch out for: Caller must have Administrator role. For SAML users, set saml_user:true; password fields are not accepted for SSO users.

Request example

POST /api/authn/v2/users
Content-Type: application/json
{
  "user_name":"bob@example.com",
  "first_name":"Bob",
  "last_name":"Jones",
  "email_address":"bob@example.com",
  "roles":[{"role_name":"Reviewer"}]
}

Response example

{
  "user_id": "b2c3d4e5-...",
  "user_name": "bob@example.com",
  "active": true
}

Update user (full)

• Method: PUT
• URL: https://api.veracode.com/api/authn/v2/users/{userId}
• Watch out for: PUT replaces the full user object; omitting roles will remove existing role assignments.

Request example

PUT /api/authn/v2/users/b2c3d4e5-...
Content-Type: application/json
{
  "first_name":"Robert",
  "roles":[{"role_name":"Security Lead"}]
}

Response example

{
  "user_id": "b2c3d4e5-...",
  "first_name": "Robert",
  "roles": [{"role_name":"Security Lead"}]
}

Partial update user

• Method: PUT
• URL: https://api.veracode.com/api/authn/v2/users/{userId}?partial=true
• Watch out for: Use ?partial=true query parameter to perform a partial update (PATCH-like behavior). Without it, omitted fields may be cleared.

Request example

PUT /api/authn/v2/users/b2c3d4e5-...?partial=true
Content-Type: application/json
{"active": false}

Response example

{
  "user_id": "b2c3d4e5-...",
  "active": false
}

Delete user

• Method: DELETE
• URL: https://api.veracode.com/api/authn/v2/users/{userId}
• Watch out for: Deletion is permanent. Consider deactivating (active:false) instead to preserve audit history.

Request example

DELETE /api/authn/v2/users/b2c3d4e5-...
Authorization: VERACODE-HMAC-SHA-256 ...

Response example

HTTP 204 No Content

List teams

• Method: GET
• URL: https://api.veracode.com/api/authn/v2/teams
• Watch out for: Teams control application visibility; assigning a user to a team grants access to that team's applications.

Request example

GET /api/authn/v2/teams?page=0&size=50
Authorization: VERACODE-HMAC-SHA-256 ...

Response example

{
  "_embedded": {
    "teams": [{"team_id":"t1","team_name":"AppSec Team"}]
  }
}

Get current user (self)

• Method: GET
• URL: https://api.veracode.com/api/authn/v2/users/self
• Watch out for: Useful for verifying API credential identity and role assignments without needing the user_id.

Request example

GET /api/authn/v2/users/self
Authorization: VERACODE-HMAC-SHA-256 ...

Response example

{
  "user_id": "...",
  "user_name": "caller@example.com",
  "roles": [{"role_name":"Administrator"}]
}

• Rate limits: Veracode does not publicly document specific rate-limit thresholds or headers for the Identity API.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No official rate-limit figures or headers documented. HTTP 429 responses may occur under heavy load; implement exponential back-off.

• Pagination method: offset

• Default page size: 50

• Max page size: 100

• Pagination pointer: page / size (Spring Data REST HAL pagination: ?page=0&size=50)

• Webhooks available: No

• Webhook notes: Veracode does not document a native webhook system for user-management events.

• Alternative event strategy: Poll the Identity API (GET /users) on a schedule to detect changes, or use Veracode's SAML/SCIM provisioning via an IdP (Okta, Entra ID) to receive provisioning events on the IdP side.

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

Limitations:

• Veracode does not expose a native SCIM 2.0 endpoint directly.
• Automated provisioning is achieved via IdP connectors (Okta SAML app, Microsoft Entra ID SAML app) using SAML JIT or the Identity REST API.
• Enterprise plan and SSO configuration are prerequisites for IdP-based automated provisioning.
• No SCIM connector is listed in Veracode's official documentation as of the research date.

Three scenarios cover the majority of automation use cases.

First, provisioning a new SSO user: POST to /users with saml_user:true and the desired roles array, capture the returned user_id, then use PUT /users/{userId}?partial=true to assign team membership

omitting saml_user creates a local-password account that may conflict with SSO enforcement.

Second, deactivating a departed employee: retrieve the user_id via GET /users filtered by user_name, then PUT /users/{userId}?partial=true with {"active":false};

prefer this over DELETE to preserve the user's audit trail in scan history, and handle API credential revocation as a separate out-of-band step since UI deactivation does not cascade to API credentials.

Third, bulk access review: paginate GET /users with ?page=0&size=100, iterate through all pages using total_pages from the HAL response envelope, and extract user_id, roles, teams, active, and saml_user per record for export to an IGA tool or CSV.

Provision a new SSO user and assign to a team

1. Ensure SAML SSO is configured for the Veracode account (platform admin prerequisite).
2. POST /api/authn/v2/users with user_name, email_address, first_name, last_name, saml_user:true, and desired roles array.
3. Capture the returned user_id from the 201 response.
4. GET /api/authn/v2/teams to find the target team_id.
5. PUT /api/authn/v2/users/{userId}?partial=true with body {"teams":[{"team_id":""}]} to assign the team.
6. Verify by GET /api/authn/v2/users/{userId} and confirm teams and roles are correct.

Watch out for: saml_user must be true for SSO accounts; omitting it creates a local-password user which may conflict with SSO enforcement policies.

Deactivate a departed employee

1. GET /api/authn/v2/users?user_name=alice@example.com to retrieve the user_id (filter by user_name if supported, else paginate and match).
2. PUT /api/authn/v2/users/{userId}?partial=true with body {"active":false} to deactivate the account.
3. Confirm HTTP 200 and active:false in the response.
4. Optionally remove team memberships: PUT /api/authn/v2/users/{userId}?partial=true with {"teams":[]}.

Watch out for: Prefer deactivation over DELETE to preserve the user's audit trail within Veracode scan history.

Bulk-list all users for an access review

1. GET /api/authn/v2/users?page=0&size=100 and capture total_pages from the response.
2. Iterate pages 0 through total_pages-1, collecting all user objects.
3. For each user, record user_id, user_name, email_address, roles, teams, active, and saml_user fields.
4. Export to CSV or feed into your IGA tool for review.

Watch out for: Max page size is 100. Large accounts may require many requests; implement back-off if HTTP 429 is encountered.

Several behaviors in the Identity API are non-obvious and will cause silent data loss or security gaps if not handled explicitly. PUT without ?partial=true is a full object replacement - omitting the roles or teams array in the request body removes all existing assignments with no warning.

No official rate-limit thresholds or rate-limit response headers are documented; HTTP 429 responses can occur under load, and callers must implement exponential back-off independently. Pagination uses zero-based Spring Data REST HAL format (?page=0&size=N), not cursor-based;

the maximum page size is 100, and large accounts will require many sequential requests. SAML users cannot have passwords set via the API - the saml_user flag must be set at creation time and SSO must already be configured at the platform level. Finally, Veracode does not expose a native SCIM 2.0 endpoint;

automated provisioning at scale requires either direct use of this Identity REST API or IdP-side connectors (Okta, Entra ID) using SAML JIT, and no webhook system exists for user-management events, making scheduled polling the only native change-detection mechanism.