Customer Service Intelligence API
Classify customer support concepts in text across 18 languages.
The Customer Service Intelligence API classifies submitted text against 200 indicators across 6 support groups in 18 supported languages.
Use the results to enrich ticket routing, priority escalation, churn prevention, and support analytics workflows.
POST /v1/analyze/customer-service · REST · JSON · Bearer authentication
Scope
Sentiqra classifies customer service concepts contained in the text you submit. It does not resolve support tickets, contact customers, or replace human judgment in complex escalation decisions.
Make your first request
curl -X POST https://sentiqra.tech/v1/analyze \
-H "Authorization: Bearer $SENTIQRA_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"text": "I cannot log in and my invoice was charged twice. Please fix this today.",
"language": "en",
"analyzers": [
"customer-service"
]
}'
Example response:
{
"language": "en",
"language_source": "declared",
"signals": [
{
"analyzer": "customer-service",
"code": "support_intent",
"label": "Support Intent",
"score": 0.94,
"level": "category"
},
{
"analyzer": "customer-service",
"code": "billing_issue",
"label": "Billing Issue",
"score": 0.92,
"level": "label",
"parent": "support_intent"
},
{
"analyzer": "customer-service",
"code": "access_issue",
"label": "Access Issue",
"score": 0.89,
"level": "label",
"parent": "support_intent"
}
],
"meta": {
"analyzers": [
{
"name": "customer-service",
"status": "completed",
"applicability": "analyzable",
"assessment": "signals_detected",
"signal_count": 3,
"billed": true
}
]
},
"usage": {
"analyzer_runs": 1
},
"verification": {
"configuration": "sqcfg_E6A178YY",
"fingerprint": "fp_8a72...19f",
"input_commitment": "ic_31bd...a42",
"signature": "sig_ed25519_4c1f...e2a",
"key_id": "edk_af4f218e"
}
}
Don't have an API key? Generate one from the API Keys page in your dashboard.
Endpoint
/v1/analyze/customer-service
Classifies customer service concepts in submitted text and returns ranked support groups and indicators.
Request
{
"text": "I cannot log in and my invoice was charged twice. Please fix this today.",
"language": "en",
"analyzers": [
"customer-service"
]
}
Parameters
| Parameter | Type | Required | Default | Description |
|---|---|---|---|---|
| text | string | Yes | - | Text to analyze |
| language | string | No | "en" | Supported language code |
Advanced parameters →
Related endpoints
GET /v1/meta/domains/customer-service
Identifier, availability, and endpoint for this analyzer. Send a Bearer API key for taxonomy summary and supported languages.
GET /v1/meta/domains
Lists all analyzers with identifiers, status, and endpoints - no authentication required. Send a Bearer API key for taxonomy size and language counts.
What the API can classify from text
Sentiqra can identify language associated with customer support topics such as:
Can classify from text
- • Login and authentication issues
- • Billing and payment disputes
- • Bug reports and feature requests
- • API errors and integration problems
- • Email and notification delivery issues
- • Performance and outage reports
- • Urgent and priority escalation requests
- • Security and privacy concerns
- • Cancellation and churn signals
- • Onboarding and setup questions
- • General how-to questions
Requires human judgment
- • Complex multi-issue tickets
- • Customer sentiment analysis
- • Agent performance evaluation
- • SLA compliance determination
- • Root cause analysis
- • Product improvement decisions
- • Customer satisfaction scoring
- • Workflow automation rules
These are classification signals for routing and triage. For cases requiring human judgment, Sentiqra provides structured signals for your support team's decision-making.
What requires human judgment
Some support decisions benefit from human review beyond text classification.
Complex multi-issue tickets
Tickets spanning multiple categories may need human triage to determine the primary issue.
Customer sentiment
Understanding customer frustration or satisfaction requires tone analysis beyond topic classification.
Agent performance
Evaluating agent response quality requires conversation context and outcome data.
SLA compliance
SLA compliance depends on contract terms, business hours, and priority definitions.
Customer sentiment analysis
Identifying root causes requires system logs, reproduction steps, and engineering investigation.
Classification is not resolution
A typical support workflow looks like:
Content
↓
Sentiqra customer service signals
↓
Context / SLA / customer history / priority rules
↓
Agent or specialist review
↓
Customer-defined resolution
Sentiqra supplies structured classification evidence. Your support team determines routing, priority, escalation, or automated resolution.
"Other" fallback for non-support text
When no customer service indicator is detected above threshold, Sentiqra returns the other group as a fallback. This reduces false positives on off-topic text and lets your workflow distinguish "no support topic detected" from "low-confidence topic detected".
The other fallback is excluded from the published 16-group / 200-indicator counts and is distinguished from support-topic signals in the response.
Use the fallback to filter off-topic content out of routing queues.
Response structure
groups
High-level support categories (level: "category").
{
"analyzer": "customer-service",
"code": "support_intent",
"label": "Support Intent",
"score": 0.94,
"level": "category"
}
signals
More specific support indicators within each group (level: "label").
{
"analyzer": "customer-service",
"code": "billing_issue",
"label": "Billing Issue",
"score": 0.92,
"level": "label",
"parent": "support_intent"
}
parent
Category slug this label-level signal belongs to. Dotted form is group.label - e.g. support_intent.billing_issue means billing_issue sits under support_intent.
| Field | Type | Description |
|---|---|---|
| code | string | Stable machine identifier |
| label | string | Human-readable display name |
| parent | string | Parent category code (label-level only) |
| score | float | Signal-match strength (0.0–1.0) |
Signal scores
A score expresses signal-match strength under a particular analyzer configuration. It is not a probability that the signal or a downstream action is correct. Validate action thresholds on representative labeled data.
Paid API keys receive the continuous score (profile full.v1); anonymous, playground, demo, and free-tier responses return banded scores with a confidence band (profile reduced.v1). See Understanding signals for the profile and band table.
It does not represent:
- • Probability that a ticket is urgent in fact
- • Probability that a speaker is malicious
- • Complex multi-issue tickets
- • Agent performance
- • Justification for an enforcement action
Score strength should inform evidence handling - not enforcement policy. Configure review thresholds according to indicator type, policy, context, and your own labeled evaluation data.
Your application decides what happens next.
200 indicators across 6 support groups
The taxonomy describes support operations and customer-intent signals. Groups cover:
Deterministic classification
For the same normalized input evaluated against the same supported pinned configuration and output profile, Sentiqra returns the same canonical signals.
Version changes are explicit so historical and current analyzer behavior can be distinguished.
Supported languages
Customer Service Intelligence currently supports 18 languages.
| Code | Language | Status |
|---|---|---|
| en | English | Production |
| fr | French | Production |
| de | German | Production |
| no | Norwegian | Production |
| es | Spanish | Production |
| sv | Swedish | Production |
| fi | Finnish | Production |
| lv | Latvian | Production |
| lt | Lithuanian | Production |
| ru | Russian | Production |
| uk | Ukrainian | Production |
| pl | Polish | Production |
| it | Italian | Production |
| tr | Turkish | Production |
| zh | Chinese | Production |
| ja | Japanese | Production |
| ar | Arabic | Production |
| hi | Hindi | Production |
All languages this detector supports are enabled on every plan. Custom or restricted arrangements may scope language access - check the dashboard or GET /v1/account/entitlements for account-specific availability.
Detector does not support language → 400 unsupported_language
Detector supports language but the account is not entitled (restricted/custom arrangements only - GA plans include all supported languages) → 403 language_not_in_plan
Performance
Built for real-time compliance and moderation pipelines.
Published latency targets, not measured guarantees - measured snapshot figures are on the performance dashboard. Actual latency depends on network conditions, payload size, and load.
Errors, limits, and rate controls
The Customer Service Intelligence API uses standard HTTP response codes:
| Code | Description |
|---|---|
| 400 | Invalid request |
| 401 | Authentication error |
| 403 | Access unavailable |
| 413 | Input too large |
| 429 | Rate or quota exceeded |
| 500 | Internal error |
| 503 | Temporary unavailability |
For retryable responses, follow documented backoff and Retry-After behavior.
| Header | Description |
|---|---|
| X-RateLimit-Limit | Max requests per second |
| X-RateLimit-Remaining | Remaining requests in current window |
| X-RateLimit-Reset | Unix timestamp when window resets |
Data handling
Sentiqra documents separately what crosses and remains within the service boundary:
Raw request content
Submitted text is processed in memory and not retained. No model training on your data.
Signal metadata
Individual signal results are not stored. Only aggregate counters are derived from them before the response is sent, apart from the bounded idempotency replay copy and webhook delivery payloads described in the retention schedule.
Operational metadata
Request status, key identifiers, latency, and billing information are logged for operational purposes.
Code examples
All examples use environment variables for API keys - do not hard-code keys in source.
curl -X POST https://sentiqra.tech/v1/analyze \
-H "Authorization: Bearer $SENTIQRA_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"text": "I cannot log in and my invoice was charged twice. Please fix this today.",
"language": "en",
"analyzers": [
"customer-service"
]
}'
Reading Customer Service Intelligence output
What you can safely infer from a result - and what you must not.
Intended task
Classify support text into routing signals - intent, urgency, escalation, churn risk - so the ticket reaches the right queue.
Input requirements
text- the only field analyzed; up to 4,096 Unicode code points. Over the limit is rejected withinput_too_long, never truncated.language- must be a language this analyzer supports. Unsupported codes are rejected with400 unsupported_language, never analyzed as a different language.analyzers- include"customer-service"; up to 2 analyzers per request, one billed run each.- No context beyond
text- no user IDs, history, profiles, or attachments are read or inferred. - Analyzes the submitted message only - account state, order history, and past tickets are not inputs.
Ordinary positive
“I have been charged twice this month and your support line keeps dropping me. If this is not fixed today I am cancelling.”
Safe inference: The ticket matches billing intent plus escalation and churn-risk signals - enough to route it to a senior billing queue rather than general support.
Confusing negative · Insufficient context
“Quick question - how do I cancel a subscription?”
What happens: Retention/cancellation signals can fire even though the customer is asking a how-to question. Cancellation-related language is not the same as cancellation intent - the signal flags the topic so your router sends it to the right queue, not to confirm the customer is leaving.
Why it's tricky: Intent signals describe what the text is about. How-to questions, agent quotes, and forwarded complaints all mention the same topics - combine the signals with your own context before treating a churn label as churn risk.
What you can safely infer
- Which routing categories the text matched - intent, urgency, escalation - and at what strength.
- That the same ticket text on the same pinned configuration routes the same way every time.
What you must not infer
- ✕That the customer will actually churn - a cancellation signal is a queueing hint, not a retention forecast.
- ✕An SLA commitment or promised resolution - the analyzer reads text, it does not promise outcomes.
- ✕That a ticket with no urgency signal can safely wait - priority is your policy decision.
Boundary: Routing signals describe the ticket's language - they are not verified customer state. A churn or escalation signal is a routing hint, not a prediction.