Classification
Classify a business into NAICS, SIC, workers comp, or general liability codes with POST /marvin2.
Overview
/marvin2Send at least a company name. Adding city, state, or a full address usually improves match quality. Each successful call consumes one Marvin2 API quota unit.
Successful responses include the X-Marvin2-Cache header (HIT or MISS). See Caching for how caching works. Use accuracy on each prediction for automation thresholds — see Confidence scores.
For the complete field list and error codes, see the classification API reference.
Example request
POST /marvin2
Read the response
Predictions are grouped under a key that depends on predictionType. For NAICS 2022, look at usa_naics_2022_prediction_hp:
prediction_a— primary classificationprediction_b— alternate classification (when you request two predictions)
Each prediction includes code, title, and accuracy (from 0.10 to 0.95).
Optional top-level fields (when enabled in responseConfig) include keywords, company_website, existence_check, and business_description. The response also includes responseId and timestamp for logging and support.
Example response (abbreviated)
Search modes
| Mode | Request value | Best for |
|---|---|---|
| Balanced (default) | searchMode: "balanced" | Highest-quality classifications when you can wait for web research |
| Fast | searchMode: "fast" | Lower latency when you need a quicker answer |
Balanced mode researches the business on the web before classifying. Fast mode returns sooner with less research.
| Field | Values | Effect |
|---|---|---|
searchIntelligence | low, medium, high | How deep web research goes in balanced mode (defaults to low when omitted) |
If you already have a reliable business description and do not need web research, use description-only mode below.
Prediction types
Set predictionType on your request. If you omit it, the API defaults to USA_NAICS_2017.
Predictions always use the same shape inside the type-specific object:
{
"prediction_a": { "code": "...", "title": "...", "accuracy": 0.85 },
"prediction_b": { "code": "...", "title": "...", "accuracy": 0.72 }
}
(prediction_b is omitted when responseConfig.numberOfPredictions is 1.)
NAICS codes
predictionType | Response key | Use when |
|---|---|---|
USA_NAICS_2017 | usa_naics_2017_prediction_hp | You need 2017 NAICS 6-digit codes (default) |
USA_NAICS_2022 | usa_naics_2022_prediction_hp | You need 2022 NAICS 6-digit codes |
Each prediction includes a 6-digit code and the official NAICS title for that vintage. Pick the vintage that matches your policy forms, filings, or downstream data warehouse.
Example
For predictionType: "USA_NAICS_2022", read classifications from usa_naics_2022_prediction_hp.prediction_a (and prediction_b if present).
SIC codes
predictionType | Response key | Use when |
|---|---|---|
USA_SIC | usa_sic_prediction_hp | You need 4-digit SIC codes |
Each prediction includes a 4-digit code and the official SIC title. Codes are validated against the Relativity6 SIC registry (same guarantee pattern as NAICS: retries, then a static fallback if needed).
Example
For predictionType: "USA_SIC", read classifications from usa_sic_prediction_hp.prediction_a (and prediction_b if present).
SIC request example
Workers comp and general liability
predictionType | Response key | Use when |
|---|---|---|
R6_WORKERS_COMP | r6_workers_comp_prediction_hp | You need workers compensation class codes |
R6_GENERAL_LIABILITY | r6_general_liability_prediction_hp | You need general liability class codes |
Choosing a type
- One request, one type — Send separate API calls if you need both NAICS 2022 and workers comp codes for the same company.
- Stable parsing — The response key tells you which code system you received.
- Same tuning fields —
responseConfig,searchMode, anddescriptionOnlyapply to everypredictionType.
Response configuration
Add a responseConfig object to your request. All fields are optional; when you omit responseConfig, the API uses these defaults:
| Field | Default |
|---|---|
numberOfPredictions | 2 |
includeExistenceCheck | true |
includeDomainSearch | true |
includeKeywords | true |
includeBusinessDescription | false |
Number of predictions
numberOfPredictions accepts 1 or 2.
2(default) — returnsprediction_aandprediction_b. Use when you want a primary and alternate code.1— returns onlyprediction_a. Use when you only need a single best match.
Optional response fields
| Field | When true | Use case |
|---|---|---|
includeExistenceCheck | Adds existence_check with exists and supporting evidence URLs | Confirm the business appears real before binding or quoting |
includeDomainSearch | Adds company_website as [domain, confidence] | Capture an inferred website for enrichment or validation |
includeKeywords | Adds keywords (activity terms from research) | Feed downstream rules, search, or human review |
includeBusinessDescription | Adds business_description (short narrative) | Pre-fill forms without a separate summarization call |
Set any of these to false to omit that data from the response.
Latency and cost tips
For high-volume or latency-sensitive workflows, combine a lean responseConfig with searchMode: "fast":
Lean request example
Start strict, then expand
Begin with the smallest response that meets your workflow (often one prediction and no optional fields). Add existence checks, keywords, or a second prediction only where your product needs them.
Description-only mode
Set descriptionOnly to true to skip web search and classify using only request fields plus your description text.
What it does
The service still returns the same prediction structure (for example usa_naics_2022_prediction_hp.prediction_a) and honors responseConfig. searchMode has no effect — web research is not performed.
Requirements
| Rule | Detail |
|---|---|
description is required | Non-empty description when descriptionOnly is true |
| Maximum length | 1,000 characters |
| Validation error | Missing description returns HTTP 400 |
Example request
Provide enough detail for a human underwriter to pick an industry code — products, customers, operations, and what the business does not do.
Description-only classification
When to use it
Good fits: you already have a detailed description in your application or CRM; testing with fixed inputs; environments where outbound web research is undesirable.
Prefer standard mode (descriptionOnly: false, default) when you want the service to discover websites, keywords, and existence evidence from the open web.
Limitations
Quality depends on your description
Vague descriptions produce weaker codes than specific ones. Prefer concrete operations language over generic labels.
- Optional fields tied to web research are usually empty or less useful — turn them off in
responseConfig. - Description-only does not bypass cache; identical bodies still return
X-Marvin2-Cache: HIT.