Influitive User Management API Guide

Auth method: API Key (token-based); passed as a request header or query parameter

Setup steps

1. Log in to your Influitive AdvocateHub as an administrator.
2. Navigate to Settings > Integrations or API settings to generate an API token.
3. Include the token in requests via the Authorization header: 'Authorization: Token token=YOUR_API_KEY'.

List advocates

• Method: GET
• URL: https://[your-hub].influitive.com/api/v1/advocates
• Watch out for: Full field list and pagination parameters not publicly documented; behavior may vary by hub configuration.

Request example

GET /api/v1/advocates
Authorization: Token token=YOUR_API_KEY

Response example

{
  "advocates": [
    {"id": 1, "email": "user@example.com", "first_name": "Jane", "last_name": "Doe"}
  ]
}

Get advocate by ID

• Method: GET
• URL: https://[your-hub].influitive.com/api/v1/advocates/:id
• Watch out for: Endpoint existence inferred from standard REST patterns in partial docs; verify against your hub's API reference.

Request example

GET /api/v1/advocates/1
Authorization: Token token=YOUR_API_KEY

Response example

{
  "advocate": {
    "id": 1,
    "email": "user@example.com",
    "first_name": "Jane"
  }
}

Create advocate

• Method: POST
• URL: https://[your-hub].influitive.com/api/v1/advocates
• Watch out for: Duplicate email handling behavior not publicly documented; test for idempotency before bulk imports.

Request example

POST /api/v1/advocates
Authorization: Token token=YOUR_API_KEY

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

Response example

{
  "advocate": {
    "id": 42,
    "email": "new@example.com"
  }
}

Update advocate

• Method: PUT
• URL: https://[your-hub].influitive.com/api/v1/advocates/:id
• Watch out for: Whether PATCH is also supported is not confirmed in public docs; use PUT for full updates.

Request example

PUT /api/v1/advocates/42
Authorization: Token token=YOUR_API_KEY

{"advocate": {"title": "VP Marketing"}}

Response example

{
  "advocate": {
    "id": 42,
    "title": "VP Marketing"
  }
}

Delete advocate

• Method: DELETE
• URL: https://[your-hub].influitive.com/api/v1/advocates/:id
• Watch out for: Deletion may be irreversible; soft-delete vs. hard-delete behavior not publicly documented.

Request example

DELETE /api/v1/advocates/42
Authorization: Token token=YOUR_API_KEY

Response example

HTTP 204 No Content

• Rate limits: No publicly documented rate limit tiers or specific request-per-minute values found in official docs.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: Rate limit details are not publicly disclosed. Contact Influitive support for current limits.

• Pagination method: offset

• Default page size: 0

• Max page size: 0

• Pagination pointer: page

• Webhooks available: Yes

• Webhook notes: Influitive supports outbound webhooks for hub events, configurable via the integrations settings. Specific event types and payload schemas are not fully detailed in public documentation.

• Alternative event strategy: Polling the advocates list endpoint can be used if webhooks are not available on a given plan.

• Webhook events: advocate.created, advocate.updated, challenge.completed, referral.submitted

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

Limitations:

• No native SCIM 2.0 support documented in official Influitive help or developer docs.
• No IdP (Okta, Entra, Google Workspace, OneLogin) SCIM connector officially listed.

Three integration scenarios are supported by the available endpoint surface, each with meaningful caveats.

For bulk advocate import, POST to /api/v1/advocates per record with email, first_name, and last_name - no batch endpoint is publicly documented, so each advocate requires an individual request;

test duplicate email handling in a staging hub before any production bulk run.

For deactivating a departed advocate, GET /api/v1/advocates to resolve the advocate's ID by email, then either PUT with status: inactive or DELETE the record

soft-delete versus hard-delete behavior is unconfirmed, so validate in a non-production environment first.

For CRM-driven profile syncs, PUT to /api/v1/advocates/:id with updated title, company, or custom_fields values;

custom field keys must exactly match those pre-configured in the hub admin, as mismatched keys may be silently ignored with no error response.

Bulk import new advocates

1. Authenticate using your hub API token in the Authorization header.
2. POST to /api/v1/advocates for each new user with required fields: email, first_name, last_name.
3. Check response for the assigned advocate ID and store for future updates.
4. Handle duplicate email errors gracefully; test behavior in a staging hub first.

Watch out for: No bulk/batch endpoint is publicly documented; each advocate requires an individual POST request.

Deactivate a departed advocate

1. GET /api/v1/advocates to find the advocate by email and retrieve their ID.
2. PUT /api/v1/advocates/:id with status set to 'inactive' (if supported) or DELETE the record.
3. Confirm the advocate no longer appears in active hub listings.

Watch out for: Soft-delete (status change) vs. hard-delete behavior is not publicly confirmed; test before production use.

Sync advocate profile updates from CRM

1. Retrieve the advocate's ID by querying /api/v1/advocates filtered by email.
2. PUT /api/v1/advocates/:id with updated fields (title, company, custom_fields).
3. Log the API response to confirm successful update.

Watch out for: Custom field keys must exactly match those configured in the hub admin; mismatched keys may be silently ignored.

The primary integration risk is documentation opacity: most endpoint contracts, error schemas, and pagination behavior are behind an authenticated developer portal, leaving implementers to infer behavior from partial references.

The static API key model introduces a rotation risk - there is no documented OAuth token refresh, so a compromised or expired key requires manual regeneration and redeployment across any dependent systems. Because Influitive has no SCIM support, any identity graph that relies on automated provisioning events from an IdP will not receive them;

lifecycle events must be explicitly triggered by an external orchestration layer. Webhooks are available for events such as advocate.created, advocate.updated, challenge.completed, and referral.submitted, but payload schemas and plan-level availability are not fully detailed in public documentation, making them unreliable as a sole sync mechanism without prior validation against your specific hub configuration.