This document contains a changelog for the SocialLadder Public APIs
Release: October 20, 2025
Endpoints: /SocialLadderAPI/api/v1/portal/agent/* and /SocialLadderAPI/api/v1/automation/*
Changes:
Beta API Endpoints Removed from Swagger Documentation
Reason for Removal:
These endpoints are part of the SL Agent AI automation platform currently in beta testing. They were inadvertently exposed in the public Swagger documentation before the feature was ready for general availability.
Functional Impact:
Public Documentation: These endpoints no longer appear at https://socialladder.rkiapps.com/swagger/ui/index#
Functionality: The endpoints remain fully functional for internal/beta users with proper authentication
Existing Integrations: No impact - these were beta endpoints with no public integrations
API Access: Endpoints still accessible via direct API calls with valid automation-scoped API keys
Release: September 19, 2025
Endpoint: POST /SocialLadderAPI/api/v1/ambassador/{ambassadorId}/vanityCode (Enhanced)
Changes:
Added isPromotional parameter to distinguish between standard and promotional voucher codes
Enhanced error handling to return proper response messages
Improved validation to check response codes before returning success
Functional Impact:
Supports creation of promotional codes with specific tracking
Better error handling returns specific error messages (duplicate code, invalid code, etc.)
Enables differentiation between regular ambassador codes and temporary promotional codes
Campaign managers can track promotional code performance separately
Breaking Change: No (Optional parameter with default value)
Endpoint: PUT /SocialLadderAPI/api/v1/ambassador/{ambassadorId}/vanityCode (Enhanced)
Changes:
Updated error messages from "vanity code" to "voucher code" for consistency
Changed "Vanity code not found" to "Voucher code not found" in 404 response
Functional Impact:
Consistent terminology in API responses
Aligns with product naming conventions (voucher code instead of vanity code)
No functional change, only messaging improvement
Breaking Change: No (Error message wording only)
NEW Endpoint: GET /SocialLadderAPI/api/v2/ambassador/{ambassadorId}/vanityCode
Changes:
New v2 endpoint returning ALL vanity codes for an ambassador with promotional flag
Returns array of codes instead of single first code
Includes IsPromotional flag for each code
Response Example:
{
"DiscountCodes": [
{
"DiscountCode": "AMBASSADOR2025",
"IsPromotional": false
},
{
"DiscountCode": "SUMMER50",
"IsPromotional": true
},
{
"DiscountCode": "FLASH24HR",
"IsPromotional": true
}
]
}
Comparison with v1:
v1: Returns only first code as single string (GET /api/v1/ambassador/{id}/vanityCode)
v2: Returns all codes with promotional flag (GET /api/v2/ambassador/{id}/vanityCode)
Functional Impact:
API consumers can see all codes assigned to ambassador, not just primary code
Distinguish between standard and promotional codes for analytics
Support use cases where ambassadors have multiple active codes
Better tracking of promotional campaign performance
Breaking Change: No (New endpoint, v1 unchanged)
Migration Guidance:
v1 endpoint remains available for backward compatibility
Use v2 when you need complete list of codes or promotional tracking
v1 returns first code only - suitable for single-code ambassadors
Release: June 4, 2025
Endpoint: POST /SocialLadderAPI/api/v1/sso/autoregister (Enhanced)
Changes:
Enhanced auto-registration endpoint for programmatic ambassador creation
Handles race conditions when multiple registration requests are made simultaneously
Updated to use new stored procedure for better performance
Enhanced logging for failure case debugging
Key Features:
Race condition handling prevents duplicate profile creation
Empty custom field values handled gracefully (not rejected)
Empty vanity codes allowed (system will generate unique code)
Atomic database operations prevent partial registrations
Detailed logging captures request data on failure
Functional Impact:
Enables bulk ambassador onboarding from external systems
Prevents duplicate profile creation during concurrent requests
Improves integration reliability with CRM systems
Better error handling and debugging capabilities
Breaking Change: No (Enhanced functionality)
Release: May 23, 2025
Endpoint: GET /SocialLadderAPI/api/v1/ambassador
Changes:
Added activeOnly parameter to filter results by ambassador status
When true, excludes ambassadors with "Unsubscribed" or "Unregistered" status
Helps API consumers get only actionable ambassadors
Functional Impact:
Simplifies filtering to active ambassadors
Reduces data transfer for API consumers who only need active users
Improves performance by filtering at database level
Useful for integrations that sync active ambassadors only
Breaking Change: No (Optional parameter with default value preserves existing behavior)
All Endpoints: Infrastructure Change
Changes:
Changed base class from ApiController to BaseApiController
Added Request.Properties["AreaId"] = AreaId for improved logging on GET v2, POST v2, and PUT v2 endpoints
Added using SCS.Controllers; namespace
Functional Impact:
Improved API logging and tracking capabilities
Better debugging support with area context in logs
No breaking changes to API behavior or response models
Breaking Change: No
Release: May 12, 2025
Endpoint: POST /api/v1/conversion, POST /api/v2/conversion, PUT /api/v2/conversion
Changes:
Removed duplicate SKU validation that blocked conversions with duplicate line items
Removed error: "Duplicate SKU on line items is not currently supported"
Functional Impact:
API now accepts conversions with duplicate SKUs (e.g., same product purchased multiple times)
Eliminated BadRequest (400) errors for valid use cases
Critical fix for merchants selling multiple quantities of same SKU in single order
Breaking Change: No (Expanded functionality)
Release: April 30, 2025
Endpoint: POST /api/v2/conversion, PUT /api/v2/conversion
Changes:
Added proper HttpResponseException handling to preserve error details
Added new catch block before generic Exception handler
Functional Impact:
Validation errors now return proper status codes (e.g., 400 BadRequest, 401 Unauthorized)
Error messages are preserved and returned to API clients
Improved debugging experience for API consumers
Better distinction between validation errors and unexpected errors
Breaking Change: No
Release: April 18, 2025
Endpoint: GET /api/v1/conversion, GET /api/v2/conversion
Changes:
Fixed pagination logic to only return PreviousPageURL when exactly 200 records are returned
Functional Impact:
PreviousPageURL now only appears when there are more pages to fetch (200 = max page size)
Clients can now reliably determine if more data is available
Last page returns empty string for PreviousPageURL instead of URL to same page
Prevents infinite pagination loops
Breaking Change: No (Improved behavior)
Release: April 11, 2025
Endpoint: GET /api/v1/conversion, GET /api/v2/conversion
Changes:
Enabled PreviousPageURL in GET responses for pagination support
Previously commented out, now actively returns pagination URL
Sets empty string when no more pages available
Functional Impact:
Clients can now paginate through conversion data using PreviousPageURL
Improved URL construction using GetHostFromHTTPRequestMessage for better proxy support
Response now includes beforeID parameter for next page navigation
Breaking Change: No (New functionality)
Release: April 2, 2025
Endpoint: POST /api/v1/conversion, PUT /api/v1/conversion, POST /api/v2/conversion, PUT /api/v2/conversion
Changes:
Added API Key validation against Shop Code for all POST and PUT endpoints
Added new 401 Unauthorized error: "Invalid ApiKey for Shop Code"
Updated POST v2 to pass areaId parameter to APIConversion method
Modified isResidual parameter handling from ternary to logical AND
Functional Impact:
Enhanced security: API key must now match the shop code in the request
Prevents cross-shop data submission with valid but wrong API key
Multi-shop merchants must use correct API key for each shop
Returns 401 Unauthorized if shop code doesn't match API key
Breaking Change: Yes - Previously accepted requests may now be rejected if wrong API key used for shop
Endpoint: POST /SocialLadderAPI/api/v1/sso/autoregister
Changes:
Fixed handling of empty custom data field values
Fixed handling of empty vanity code values
Previously rejected empty values, now accepts and handles appropriately
Functional Impact:
More flexible API - optional fields truly optional
Reduces integration errors from empty string values
System auto-generates vanity codes when needed
Breaking Change: No (Expanded functionality)
Release: March 31, 2025
NEW Endpoint: POST /SocialLadderAPI/api/v1/sso/autoregister
Changes:
Initial implementation of auto-register endpoint
Enables programmatic ambassador registration for external integrations
Supports custom data fields and vanity code assignment
Request Model:
{
"apiKey": "your-api-key",
"email": "user@example.com",
"firstName": "John",
"lastName": "Doe",
"phone": "+15551234567",
"customDataFields": [
{"key": "membershipLevel", "value": "Gold"},
{"key": "sponsor", "value": "ABC123"}
],
"vanityCode": "JOHN2025",
"sendWelcomeEmail": true
}
Response Model:
{
"Result": 1,
"ResponseMessage": "Ambassador registered successfully",
"Data": {
"ambassadorId": 12345,
"profileUrl": "https://brand.socialladder.com/ambassador/JOHN2025",
"trackingLink": "https://brand.socialladder.com/r/JOHN2025"
}
}
Functional Impact:
Automates ambassador onboarding from external systems (CRM, e-commerce)
Eliminates manual data entry
Maintains data consistency across platforms
Supports white-label deployments with custom vanity codes
Breaking Change: No (New endpoint)
Release: March 28, 2025
Endpoint: POST /api/v2/conversion
Changes:
Removed isResidual and originalOrderID as separate URL parameters
These values now come only from the request body (conversion object)
Cleaned up parameter list and Swagger documentation
Functional Impact:
Simplified API signature - reduced parameter count
IsResidual and OriginalOrderId now sourced from request body only
Eliminated potential conflict between URL parameters and body properties
Cleaner Swagger documentation
Breaking Change: Yes - Clients using URL parameters isResidual or originalOrderID must move to body properties
Release: March 28, 2025
Endpoint: GET /api/v1/conversion, POST /api/v1/conversion, PUT /api/v1/conversion
Changes:
Reverted response and request models to V1-specific types
Changed from generic models to versioned models for v1 endpoints
Model Changes:
Response: AmbassadorConversionAPIResponseModel → AmbassadorConversionAPIResponseModelV1
POST Request: AmbassadorConversionRequest → AmbassadorConversionRequestV1
PUT Request: AmbassadorConversionPutRequest → AmbassadorConversionRequest
Functional Impact:
Isolated v1 and v2 API models to prevent version conflicts
v1 models maintain backward compatibility without v2 fields
PUT endpoint model changed from AmbassadorConversionPutRequest to generic AmbassadorConversionRequest
Prepares for long-term support of both v1 and v2 endpoints
Breaking Change: No (Internal model changes, same JSON structure)
Release: March 27, 2025
Endpoint: PUT /api/v2/conversion
Changes:
Added AreaId parameter to ConversionManager.UpdateConversion() call
Added using Newtonsoft.Json; namespace for JSON handling
Enables logging of conversion updates with area context
Functional Impact:
Backend can now log which area made the update request
Improved audit trail for conversion modifications
Better debugging and support for multi-area accounts
Enables tracking of return reasons and change history
Breaking Change: No
Release: March 27, 2025
Endpoint: GET /api/v2/conversion
Changes:
Renamed query parameter from maxUpdateDate to minUpdateDate
Changed filter logic from "at or before" to "at or after"
Functional Impact:
Changed from historical filter (before date) to recent filter (after date)
More useful for incremental sync scenarios
Clients can fetch conversions updated since last sync
Better alignment with common API integration patterns
Breaking Change: Yes - Parameter name and logic changed. Clients using maxUpdateDate must update to minUpdateDate and reverse date logic.
Release: March 26, 2025
NEW Endpoint: GET /api/v2/conversion (BETA)
Changes:
Created new v2 GET endpoint with enhanced filtering capabilities
Added parameters: trackingKey, showDeletedProducts, minUpdateDate
Routes to new ConversionManager.GetConversionsForAPI() method instead of legacy UserManager
Includes pagination support with PreviousPageURL
New Parameters:
trackingKey - The tracking key of ambassador's link</param>
showDeletedProducts - Include returned items on the result?</param>
minUpdateDate - Show conversions updated at or after date</param>
Functional Impact:
Filter conversions by ambassador tracking key
Include or exclude returned/refunded products
Incremental sync support via minUpdateDate
Uses enhanced ConversionManager with product-level details
Better performance and more granular data access
Breaking Change: No (New endpoint)
Release: March 26, 2025
NEW Endpoint: POST /api/v2/conversion (BETA)
Changes:
Created new v2 POST endpoint with automatic calculation of totals from line items
Added support for ProductList with automatic TransAmount and TransUnits calculation
Added support for customer data: CustomerID, CustomerFirstName, CustomerLastName
Added support for residual/subscription conversions: IsResidual, OriginalOrderId
Added duplicate SKU validation (removed in later release)
Routes to same CampaignManager.APIConversion() with additional parameters
New Request Body Fields:
ProductList - Array of line items with SKU, Value, Units, etc.
CustomerID - External customer identifier
CustomerFirstName - Customer first name
CustomerLastName - Customer last name
IsResidual - Boolean flag for subscription/recurring payments
OriginalOrderId - Reference to original order for residual conversions
Functional Impact:
Submit detailed line-item data for commission calculation
Automatic total calculation eliminates manual math errors
Support for subscription/recurring revenue tracking
Customer data stored with conversion for reporting
Better attribution and commission accuracy at product level
Breaking Change: No (New endpoint)
Release: March 26, 2025
NEW Endpoint: PUT /api/v2/conversion (BETA)
Changes:
Created new v2 PUT endpoint for updating conversions
Routes to new ConversionManager.UpdateConversion() instead of CampaignManager.UpdateITBAttribution()
Supports updating line-item level data
Added duplicate SKU validation (removed in later release)
More comprehensive update support than v1
Functional Impact:
Enhanced update capabilities beyond just amount and units
Product-level updates supported via ProductList
Better validation and error handling
Consistent with v2 POST endpoint model structure
Breaking Change: No (New endpoint)
Release: March 18, 2025
Endpoint: GET /api/v1/conversion
Changes:
Updated documentation to indicate trackingKey and showDeletedProducts parameters are "Not functional until 03/26"
Added stubbed out placeholders "Test" data responses for upcoming V2 endpoints
Functional Impact:
Preview of upcoming v2 functionality in v1 endpoint signature
Test data injection for specific client areas during development
Parameters documented but not yet functional
Enabled testing of new response model structure before v2 launch
Breaking Change: No (Parameters ignored, documentation only)
Release: March 18, 2025
Endpoint: POST /api/v1/conversion
Changes:
Updated documentation to indicate new parameters "Not functional until 03/26"
Added conversionCookieGUID, isResidual, originalOrderID to method signature (not yet used)
Functional Impact:
Preview of upcoming functionality
Parameters accepted but not processed
Swagger documentation updated to show future capabilities
No behavior changes
Breaking Change: No
Endpoint: PUT /api/v1/conversion
Changes:
Changed request model from AmbassadorConversionRequest to AmbassadorConversionPutRequest
Specialized model for PUT operations
Functional Impact:
Dedicated model for PUT operations with appropriate fields
Clearer API contract for update operations
May exclude create-only fields from PUT request model
Breaking Change: No (Same JSON structure expected)
NEW Endpoint: PUT /SocialLadderAPI/api/v1/ambassador/{ambassadorId}/vanityCode
Changes:
New endpoint to update vanity code status (activate or delete/deactivate)
Allows programmatic management of ambassador discount codes
Supports "ACTIVE" and "DELETED" status values
Request Example:
PUT /SocialLadderAPI/api/v1/ambassador/12345/vanityCode?apiKey=abc123&vanityCode=AMBASSADOR2025&status=DELETED
Response Example (Success):
{
"DiscountCode": "AMBASSADOR2025"
}
Error Responses:
401 Unauthorized: Invalid API key
400 BadRequest: Empty vanity code
400 BadRequest: Invalid status (must be 'ACTIVE' or 'DELETED')
400 BadRequest: Invalid ambassador ID (not in area)
404 NotFound: Vanity code not found for ambassador
500 InternalServerError: Unexpected error
Functional Impact:
Enables programmatic code lifecycle management (activate/deactivate codes)
Supports automated code rotation for security
Integration with e-commerce platforms for temporary promotional codes
Allows deactivation of codes without permanent deletion (can be reactivated)
Use Cases:
Security: Deactivate compromised codes immediately via API
Code Rotation: Automated rotation of ambassador codes for compliance
Seasonal Campaigns: Activate/deactivate codes based on campaign schedule
Breaking Change: No (New endpoint)
Release: August 29, 2024
Endpoint: POST /api/v1/conversion
Changes:
Updated source parameter value from "Conversion API" to "SL API - Conversion"
Standardized source naming convention
Functional Impact:
Changed source attribution label in backend logging and reporting
Standardized naming convention across API endpoints
No change to API behavior or validation
Breaking Change: No
NOTE: For Changelogs prior to August 2024 - Reach out to Support.
