API release notes for developers

New endpoint added for classification codes

A new /classifications endpoint for International Standard Classification Council (ISCC) classification codes lets you search and retrieve classification information including code, grouping, category, specialization, and section. See List ISCC classifications.

New endpoint added for classification groups

A new /classifications/groups endpoint for ISCC classification groups shows you a list of available grouping values that can be used for record categorization and filtering. It uses a 1-hour memory cache and a filtering pattern for optimal performance. See List ISCC classification groups.

New endpoints added for record specializations

New endpoints are added for a record’s specializations on the /records endpoint. Each specialization has a unique ID (GUID). Record ownership is verified and event logging occurs for all operations. Sync notifications are also triggered.

• POST /records/{recordId}/info/specializations: Create and list record specializations
• GET /records/{recordId}/info/specializations: Get a record specialization
• PATCH /records/{recordId}/info/specializations/{id}: Update a record specialization
• DELETE /records/{recordId}/info/specializations/{id}: Delete a record specialization

Endpoints for a record's verifications now support classification IDs

Classification support is added to existing verification endpoints by introducing a classificationId field (a single GUID) that references ISCC classification codes. This allows verifications to be linked to standardized ISCC specialization classifications for better categorization. The existing specialization string field remains for backward compatibility.

• POST /records/{recordId}/info/verifications: Allows a classificationId field to be included
• PATCH /records/{recordId}/info/verifications/{id}: Allows a classificationId field to be included
• GET /records/{recordId}/info/verifications/{id}: Returns a classificationId in the response
• GET /records/{recordId}/info/verifications: Returns a classificationId in the response

Site hierarchy changes now supported via API when there are no shared accounts

The PATCH /sites/{id} endpoint now accepts re-parenting operations for sites that do not share account sources with their new parent. Two operations are now supported:

• Assigning a new top-level parent site
• Removing an existing parent (making a site top-level)

Both operations enforce pre-flight validation and automatically trigger a CRM sync notification on success.

RequestType schema endpoint now returns display labels

GET /schemas/RequestType now returns a description field alongside each enum value (New, Renewal, Expedited), consistent with other schema endpoints such as GET /schemas/age. Use the description field for human-readable display in your integration.

History address validation now returns a clear error for invalid country codes

If countryId is not a recognized value when creating or updating history data for a record using the /records/{recordId}/info/history endpoint, the API now returns a descriptive validation message instead of the generic The specified condition was not met for 'Country Id' error.

Improved email validation for records and sites

The platform now enforces email address validation when creating or updating records, sites, and users via the API. Previously, malformed email addresses could be saved without error, which could cause downstream failures.

With this fix, any request that includes an invalid email address will be rejected at the API level with a clear error, preventing bad data from entering the system in the first place.

If your integration submits email addresses via the API, make sure they are properly formatted (e.g., name@domain.com). Requests with invalid emails will now return a validation error rather than a 201 success response.

• POST/PUT /records
• POST/PUT /records/{recordId}/info/emails
• POST/PUT /sites (contactEmail field)

Improved response time for GET /scans with large record sets

The GET /scans endpoint now returns results significantly faster for organizations with more than 500 data scans. Queries are now batched, reducing response latency.

POST /records/{recordId}/info/organizationAffiliations returns incorrect error code for non-existent records

When submitting an organization affiliation for a record ID that does not exist, the API was previously returning 400 Bad Request with a field validation error (e.g., invalid email format) even though the record wasn’t found. The API now correctly returns 404 Not Found in this case, ensuring error responses reflect the actual failure reason before payload validation runs. This affects all record info write endpoints that validate input before checking record existence.

Resolved intermittent 500 errors on GET /entities/scans under load

GET /entities/scans was returning 500 errors with response times exceeding 15 seconds during periods of high traffic. The timeout issue is eliminated, improving reliability of this endpoint under load.