Quick Start
Start with healthcare.denial for claim routing, then expand into prior-auth or reimbursement workflows.
MCP Quickstart (Agents)
Hosted workflow intelligence MCP:
Remote endpoint: https://mcp.sentinelsignal.io/mcp
Smithery listing: @sentinelsignal/scoring (listing page)
Free no-signup trial key: POST https://token.sentinelsignal.io/v1/keys/trial
Hosted client guide: /portal/track/mcp-quickstart
MCP Verify index: /portal/track/verify
Trial key flow: /portal/track/trial-key
Install and run the local MCP server:
uvx sentinel-signal-mcp
Hosted remote MCP endpoint (Streamable HTTP): https://mcp.sentinelsignal.io/mcp
Smithery listing: @sentinelsignal/scoring (gateway URL)
Drop this MCP config into Claude Desktop, Cursor, or Windsurf (same config shape):
{
"mcpServers": {
"sentinel-signal": {
"command": "uvx",
"args": ["sentinel-signal-mcp"],
"env": {
"SENTINEL_BASE_URL": "https://api.sentinelsignal.io",
"SENTINEL_TOKEN_BASE_URL": "https://token.sentinelsignal.io"
}
}
}
}
SENTINEL_API_KEY is optional. If omitted, the local MCP server auto-mints a trial key via POST https://token.sentinelsignal.io/v1/keys/trial. PyPI: sentinel-signal-mcp. Smithery-hosted connections collect the key and forward it as x-sentinel-api-key.
ChatGPT, Claude, and Smithery setup steps plus copy-paste prompts live at /portal/track/mcp-quickstart. Reviewer package: Anthropic Connectors Directory Reviewer Kit.
Canonical Demo Flows
- Trial key -> first healthcare score -> verify limits and usage
- Hosted MCP ->
score_workflow for denial review or reimbursement analysis inside an agent runtime
- Same-key upgrade -> Stripe checkout -> continue calling the same API key
Detailed walkthrough: Three Demo Flows for Denial-Risk Triage.
1. Get an API Key
Fastest path: mint an instant no-signup trial key with POST /v1/keys/trial (no auth required).
curl -X POST https://token.sentinelsignal.io/v1/keys/trial
Trial keys can call workflow discovery and scoring surfaces: GET /v1/workflows, GET /v1/workflows/{workflow}/schema, POST /v1/workflows/{workflow}/validate, POST /v1/score, POST /v1/score/batch, GET /v1/limits, and GET /v1/usage, then upgrade the same key via POST /v1/billing/checkout-session (Bearer trial key) when quota is exhausted.
Start free via dashboard self-serve signup/login, then create a key under /v1/control-plane/workspace/api-keys.
Admin-assisted issuance remains available via POST /v1/apikeys/issue.
Self-serve onboarding is available through dashboard auth endpoints:
POST /v1/control-plane/auth/signup,
POST /v1/control-plane/auth/login, and workspace/key lifecycle under
/v1/control-plane.
One-time setup links remain available for admin-assisted onboarding.
Workspace rename/update uses POST /v1/control-plane/workspace with payload {"workspace_name":"..."}.
For paid plans, start Stripe Checkout from /portal/dashboard (self-serve), use POST /v1/billing/checkout-session (API-key-auth trial upgrade), or use POST /v1/billing/checkout/session (admin flow).
Include the key in all requests:
Authorization: Bearer YOUR_API_KEY
Field Mapping Quickstart (Caller-Owned IDs)
These values come from your claim source system and should stay stable across requests. They are not API credentials.
provider_id: provider master key from your source systempayer_id: payer/plan master key from your source systempatient_id (optional): patient/member key (tokenized or hashed is acceptable)place_of_service (optional): 2-digit CMS POS code such as 11, 22, or 23
Drop-in mapping templates for common source shapes:
// Template A: 837 / clearinghouse style row
{
"provider_id": 1021,
"payer_id": 44,
"patient_id": "PT00012345",
"place_of_service": "11"
}
// Template B: EHR encounter + charge export
{
"provider_id": 30455,
"payer_id": 2207,
"patient_id": "MRN-009871",
"place_of_service": "22"
}
// Template C: Internal work-queue row (tokenized member id)
{
"provider_id": 88,
"payer_id": 901,
"patient_id": "tok_7f3a4b2c",
"place_of_service": "23"
}
Launch note: Caller-Owned IDs and Validate-First Guard for Faster Integrations.
2. Make Your First Request
curl https://api.sentinelsignal.io/v1/score \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"workflow": "healthcare.denial",
"payload": {
"external_claim_id": "CLM-SS-0001",
"service_date": "2026-02-14",
"provider_id": 1021,
"payer_id": 44,
"cpt_code": "99213",
"icd10_code": "E119",
"billed_amount": 250.00,
"place_of_service": "11",
"network_status": "in_network"
},
"options": {
"operating_point": "high_recall",
"distribution_profile": "commercial_beta"
}
}'
3. Response
{
"workflow": "healthcare.denial",
"score": 0.81,
"risk_level": "high",
"confidence": 0.92,
"model_version": "0.3.3",
"explanation": {
"top_factors": [...]
},
"details": {
"workflow": "healthcare.denial",
"denial": {
"denial_probability": 0.81,
"operating_point": "high_recall",
"distribution_profile": "commercial_beta",
"routing_source": "explicit"
}
},
"scored_at": "2026-02-14T12:00:00Z"
}
4. Check Usage and Limits
GET /v1/limits
GET /v1/usage
Workflow Discovery and Validation
Use workflow metadata to remove guesswork before the first score.
# 1) Discover workflows and pull the canonical payload schema
GET /v1/workflows
GET /v1/workflows/healthcare.denial/schema
# 2) Validate candidate payloads (no scoring call consumed)
POST /v1/workflows/healthcare.denial/validate
# 3) Submit validated payloads
POST /v1/score
POST /v1/score/batch
GET /v1/workflows/{workflow}/schema returns required fields, optional fields, the request schema, and an example payload. POST /v1/workflows/{workflow}/validate returns normalized payload output and structured validation errors without consuming a scoring call.
Example validation failure to catch early: place_of_service must be a 2-digit POS code, so values like OFFICE should fail at validation before you call /v1/score.
5. Submit Outcome Feedback (Optional)
Use the scoring response x-request-id when posting feedback telemetry:
POST /v1/feedback
{
"request_id": "<x-request-id-from-score-response>",
"endpoint": "denial",
"observed_outcome": "denied",
"expected_outcome": "paid",
"confidence_mismatch": true,
"notes": "Unexpected denial after review"
}
Feedback calls are telemetry-only and are not counted as billable scoring calls.