From text to protected text.

A short path to your first request, with the detail you need for production integration.

Your first API call

Log in to Dashboard, choose a plan or pack and create an API key. Keys are shown once. Store yours in a secret manager or environment variable, outside source code.

Production base URL: https://api.shinrai.innovius.io

curl https://api.shinrai.innovius.io/v1/analyze \
  -H "Authorization: Bearer $SHINRAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"Emma Weber, emma@example.com","tier":"standard"}'

The response contains detected entities and their offsets, plus usage.weighted_records and the remaining balance. This short Standard request uses one record. Entity predictions and replacement names depend on the model and input.

Detect personal data

POST /v1/analyze accepts a single text or a texts array. Native offsets count Unicode code points, starting at zero; endIndex is exclusive.

GET /v1/models lists the models and API tiers available to your key. OpenAPI is the machine-readable native reference.

Replace personal data and keep the mapping

POST /v1/redact returns transformed text. Choose replace for consistent realistic stand-ins, mask for masked characters, or label for entity labels such as [PERSON].

curl https://api.shinrai.innovius.io/v1/redact \
  -H "Authorization: Bearer $SHINRAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"Contact Emma at emma@example.com","mode":"replace"}'

Save the returned mapping securely in your application if you need restoration. Send known_replacements to reuse existing stand-ins across calls; reserved_replacements excludes values that must not be generated. mask_char controls masking and defaults to *.

Review detections against representative documents. Pseudonymized text and restoration mappings can remain sensitive data; do not treat transformation as a guarantee of anonymization.

Migrating from Azure Language PII

Use your ShinrAI API key in Ocp-Apim-Subscription-Key and point the client at the ShinrAI API base URL. The text PII adapter implements the supported request and response contracts below; model predictions and full Azure feature coverage are separate concerns.

curl 'https://api.shinrai.innovius.io/language/:analyze-text?api-version=2023-04-01' \
  -H "Ocp-Apim-Subscription-Key: $SHINRAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"kind":"PiiEntityRecognition","analysisInput":{"documents":[{"id":"1","language":"en","text":"Email emma@example.com"}]},"parameters":{"modelVersion":"latest","stringIndexType":"Utf16CodeUnit"}}'

Synchronous text PII allows up to 5 documents of 5,120 grapheme clusters each. Asynchronous jobs allow up to 25 documents and 125,000 Unicode 8 text elements in total, with a 1 MiB request limit. Follow the returned operation-location URL for polling. Job access and cancellation are restricted to the creating account; encrypted job data expires 24 hours after submission.

Offset modes include UTF-16 code units, Unicode code points and Unicode 8 text elements. The actual model is ShinrAI 1.3; dated Azure model identifiers are rejected. The current model does not cover every Azure PII category or modality. Unsupported category/options requests fail explicitly. This is a text PII adapter, with additional compatibility detail in the release matrix; it is not a claim of Azure-wide feature or prediction parity.

See record examples →

Records, tiers and billing cycles

A base record is up to 1,000 Unicode code points per text, rounded up separately for each text, with a minimum of one. The API tier applies its weight to that base count. Fractions are preserved in tenths of a record.

For example, two 800-character texts use 2 Standard records, 1 Batch record or 3.2 Real-Time records. Native Batch is a lower-priority processing tier; asynchronous Azure jobs are a separate request lifecycle.

Plan allowance is used first, then pack records. Monthly allowance resets at the billing boundary and does not roll over. Packs do not expire. An upgrade requires payment and starts a new cycle with the full new allowance; a downgrade or cancellation takes effect at the current period’s end. Review the charge preview in Dashboard before confirming a change.

See consumption in Dashboard or GET /v1/usage. The billing portal provides invoice PDFs, company details and payment methods. Appropriate tax is calculated during checkout and invoices are emailed after purchase.

Errors and retries

Native API errors use {"error":{"code":"…","message":"…"}}. Azure-compatible endpoints use their own error envelopes. Preserve X-Request-Id for troubleshooting.

Validation failures and work rejected before processing do not consume records. A connection loss is not proof that processing failed: keep the request reference and check usage before blindly retrying a large workload. Synchronous results are not stored for replay.

Data handling and keys

Synchronous text and replacement mappings are processed in memory. Operational usage records contain identifiers, counts and timings rather than document contents. Asynchronous job inputs and results require encrypted temporary storage and expire after 24 hours. Your application controls retention of its returned results and mappings.

Create and revoke API keys in Dashboard. Starter supports one key; higher plans support up to five. Production keys start with shr_live_, sandbox keys with shr_test_. They belong to separate environments. Do not embed them in browser applications, URLs or support messages.

Test your integration

Start with synthetic data and verify detection, replacement and usage before sending production traffic.

For coordinated QA testing, request separate test access from our team. Test credentials and checkout vouchers are provided with the private testing guide.