/v1/diacritize
Diacritization
Add Persian short vowels and optional Ezafe while keeping the submitted letters, punctuation, spacing, and ZWNJ intact.
- Marked Persian
- Source-indexed operations
- Optional Ezafe evidence
VowelMarks API
Add source-preserving diacritics, readable Pinglish, word-origin insights, and Persian-to-English translation through one developer interface.
Private developer access. Keys are issued manually.
POST /v1/diacritize
Authorization: Bearer vm_...
{
"text": "کتاب جدید",
"include_ezafe": true
}
// response
{
"original": "کتاب جدید",
"marked": "کِتابِ جَدید",
"operations": [...]
}Current status
This page describes the intended developer product and pilot pricing. There is no public key dashboard, automated billing, or instant activation today. We review each early integration directly before issuing access.
One key, four capabilities
Each endpoint returns structured evidence alongside its text result. Translation remains separate from the reading-cue pipeline.
/v1/diacritize
Add Persian short vowels and optional Ezafe while keeping the submitted letters, punctuation, spacing, and ZWNJ intact.
/v1/pinglish
Turn Persian script into pronunciation-first Latin text using either a readable heritage style or a systematic style.
/v1/word-insights
Identify supported word origins and suggest context-sensitive Persian alternatives without rewriting the source sentence.
/v1/translate
Translate Persian into English as a separate result so products can preserve Persian as the primary reading surface.
Pilot pricing
These are the intended early-access rates. Exact limits and terms are confirmed with you before a key or invoice is issued.
Returned marks, metadata, and English output do not add credits.
For testing one integration before committing to a paid pilot.
For prototypes, small learning tools, and low-volume production use.
For established apps adding Persian reading support to regular workflows.
For higher-volume platforms that need coordinated capacity planning.
Higher volume
Tell us about monthly text volume, latency needs, regions, and support requirements.
Why this model
A 50-character lookup should not cost the same as a 5,000-character article.
One balance lets a product combine marks, Pinglish, origins, and translation as needed.
Billing follows submitted text, not the number of marks or metadata fields returned.
API questions
Not through a dashboard yet. Public key management and automated billing have not been built. Early keys are issued manually after we review the use case, expected volume, and data requirements with you.
A request might contain one word or several pages. Input-character billing makes those workloads comparable and prevents short requests from subsidizing unusually large ones.
The planned meter counts Unicode code points in the submitted input, including spaces and punctuation. Added diacritics and returned metadata do not add to the input count.
Yes. The pilot design uses one shared credit balance across diacritization, Pinglish, word insights, and translation, with no separate feature subscription.
The intended policy is to charge successful responses, not validation errors or VowelMarks service failures. Provider-attempt and retry details will be written into the pilot terms before access begins.
Not during manual pilot access. Products with uptime, throughput, regional processing, or contractual support requirements should describe those needs in the access request.
Start with a conversation
Include your product, endpoints, expected text volume, and launch timing. We will reply with fit, current limitations, and pilot terms.