We are currently building something exciting and will be launching soon. Registration is temporarily closed. Launching soon — registration temporarily closed.

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

POST /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
textstringYes-Text to analyze
languagestringNo"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
codestringStable machine identifier
labelstringHuman-readable display name
parentstringParent category code (label-level only)
scorefloatSignal-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:

Access Account
Billing Retention
Product Tech
Delivery Status
Escalation Urgency
Security Feedback

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

View language coverage and benchmarks →

Performance

Built for real-time compliance and moderation pipelines.

p50 < 200ms
Median response time (single request)
p95 < 500ms
95th percentile latency - published target

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
400Invalid request
401Authentication error
403Access unavailable
413Input too large
429Rate or quota exceeded
500Internal error
503Temporary unavailability

For retryable responses, follow documented backoff and Retry-After behavior.

Header Description
X-RateLimit-LimitMax requests per second
X-RateLimit-RemainingRemaining requests in current window
X-RateLimit-ResetUnix timestamp when window resets
View current pricing and limits →

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"
    ]
}'

Use an SDK

Official SDKs are available for Python, JavaScript, Go, and PHP.

View SDK preview →

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 with input_too_long, never truncated.
  • language - must be a language this analyzer supports. Unsupported codes are rejected with 400 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.”

billing_payments very high
retention_cancellation high
escalation high

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.