Partnerize User Management API Guide

Auth method: API Key (dual-key: application_key + user_api_key passed as HTTP headers or query parameters)

Setup steps

1. Log in to the Partnerize platform as an account administrator.
2. Navigate to Account Settings > API Keys to retrieve your application_key (network-level) and user_api_key (user-level).
3. Include both keys in every API request: as HTTP headers X-Application-Key and X-User-Api-Key, or as query parameters application_key and user_api_key.
4. Ensure the user account associated with the user_api_key has sufficient permissions for the operations you intend to perform.

List users

• Method: GET
• URL: https://api.partnerize.com/user
• Watch out for: Pagination uses page and count query parameters; default page size is 100.

Request example

GET /user?application_key=APP_KEY&user_api_key=USER_KEY HTTP/1.1
Host: api.partnerize.com

Response example

{
  "users": [
    {"user_id": "123", "firstname": "Jane", "lastname": "Doe", "email": "jane@example.com", "status": "active"}
  ],
  "count": 1
}

Get user by ID

• Method: GET
• URL: https://api.partnerize.com/user/{user_id}
• Watch out for: Requires the requesting user's API key to have read permissions on user resources.

Request example

GET /user/123?application_key=APP_KEY&user_api_key=USER_KEY HTTP/1.1
Host: api.partnerize.com

Response example

{
  "user": {
    "user_id": "123",
    "firstname": "Jane",
    "lastname": "Doe",
    "email": "jane@example.com",
    "status": "active"
  }
}

Create user

• Method: POST
• URL: https://api.partnerize.com/user
• Watch out for: Email must be unique. Password requirements are not publicly documented; test against the API for validation errors.

Request example

POST /user HTTP/1.1
Host: api.partnerize.com
Content-Type: application/json

{"firstname":"John","lastname":"Smith","email":"john@example.com","password":"SecurePass1!"}

Response example

{
  "user": {
    "user_id": "456",
    "firstname": "John",
    "lastname": "Smith",
    "email": "john@example.com",
    "status": "active"
  }
}

Update user

• Method: PUT
• URL: https://api.partnerize.com/user/{user_id}
• Watch out for: Partnerize uses PUT (not PATCH) for updates; omitting fields may reset them. Verify field behavior before bulk updates.

Request example

PUT /user/456 HTTP/1.1
Host: api.partnerize.com
Content-Type: application/json

{"firstname":"Jonathan","status":"inactive"}

Response example

{
  "user": {
    "user_id": "456",
    "firstname": "Jonathan",
    "status": "inactive"
  }
}

Delete user

• Method: DELETE
• URL: https://api.partnerize.com/user/{user_id}
• Watch out for: Deletion may be irreversible. Confirm whether deactivation (status=inactive) is preferred over hard deletion for audit trail purposes.

Request example

DELETE /user/456?application_key=APP_KEY&user_api_key=USER_KEY HTTP/1.1
Host: api.partnerize.com

Response example

{
  "status": "success",
  "message": "User deleted."
}

Get current authenticated user

• Method: GET
• URL: https://api.partnerize.com/user/self
• Watch out for: Useful for validating API key pairs and confirming the identity/role of the authenticating user.

Request example

GET /user/self?application_key=APP_KEY&user_api_key=USER_KEY HTTP/1.1
Host: api.partnerize.com

Response example

{
  "user": {
    "user_id": "123",
    "email": "jane@example.com",
    "role": "admin"
  }
}

• Rate limits: Partnerize does not publicly document specific rate limit thresholds or tiers in their developer documentation.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No publicly documented rate limits, headers, or Retry-After behavior found in official docs. Contact Partnerize support for enterprise-level rate limit details.

• Pagination method: offset

• Default page size: 100

• Max page size: 100

• Pagination pointer: page and count (e.g., ?page=1&count=100)

• Webhooks available: Yes

• Webhook notes: Partnerize supports webhooks (called 'postbacks' or conversion tracking notifications) primarily for partner/conversion events. User lifecycle webhooks (create, update, delete) are not documented as available.

• Alternative event strategy: Poll the user list endpoint periodically to detect user changes, as user-lifecycle webhook events are not publicly documented.

• Webhook events: conversion.approved, conversion.rejected, conversion.pending

• SCIM available: No
• SCIM version: Not documented
• Plan required: N/A
• Endpoint: Not documented

Limitations:

• No native SCIM 2.0 support documented by Partnerize.
• No IdP-native connectors (Okta, Entra ID, Google Workspace, OneLogin) are officially listed.
• User provisioning must be handled via the REST API directly.

Three automation scenarios are well-supported by the documented endpoints.

First, provisioning: POST to /user with firstname, lastname, email, and password;

capture the returned user_id;

then PUT to /user/{user_id} to set role, timezone, and locale.

Password validation rules are undocumented - handle 400 errors explicitly in your provisioning workflow.

Second, deactivation: GET /user to resolve user_id by email, then PUT status=inactive rather than issuing a DELETE, which is irreversible and eliminates audit history;

also rotate any API keys the departing user held, since those keys will break any integration they were tied to.

Third, access auditing: paginate GET /user?page=1&count=100, incrementing page until the response count drops below 100, then filter client-side for status=active - no server-side status filter is documented.

Cross-reference results against your identity provider to surface orphaned accounts.

Provision a new platform user

1. Authenticate using an admin user's application_key and user_api_key.
2. POST to /user with required fields: firstname, lastname, email, password.
3. Capture the returned user_id for future reference.
4. Optionally PUT to /user/{user_id} to set role, timezone, and locale.

Watch out for: Password policy is not publicly documented; handle 400 validation errors and surface them to the provisioning workflow.

Deactivate a departed user

1. GET /user to find the target user_id by email.
2. PUT /user/{user_id} with status set to 'inactive' to disable access without deleting the record.
3. Rotate or revoke the user's API keys via account settings if they were used in integrations.

Watch out for: Using DELETE is irreversible; prefer status=inactive to preserve audit history. Confirm exact status enum values against the live API.

Audit all active users

1. GET /user?page=1&count=100 to retrieve the first page of users.
2. Iterate pages by incrementing the page parameter until the returned count is less than 100.
3. Filter results client-side for status=active.
4. Cross-reference against your identity provider's active user list to identify orphaned accounts.

Watch out for: No server-side filtering by status is documented; full list retrieval and client-side filtering is required.

Several API behaviors warrant explicit handling before production use. The API uses PUT semantics for updates - not PATCH - meaning omitted fields may be overwritten with nulls or defaults; always GET the current object before issuing an update.

Rate limits are not publicly documented, so unexpected throttling under high request volumes is possible with no Retry-After header to guide backoff logic. API keys are scoped to a specific user account: if that account is deactivated or deleted, every integration using its keys returns 401 immediately.

API versioning is not prominently documented, so monitor the developer portal for breaking changes. Finally, Partnerize's webhook system covers conversion events only (conversion.approved, conversion.rejected, conversion.pending); user lifecycle events are not available, so detecting changes requires polling the user list endpoint on a scheduled basis.