Developers
Business context
for your models and agents.
Give your models, agents and systems what Ishara knows about people, companies and relationships, through its API and an MCP server. Every call runs under a scoped key and your team's access rules.
A work email reserves 5,000 credits ($50).
Early access in waves · Read-only API and MCP on Free · API keys and webhooks with Pro · Arabic and English
Prepare me for the 10:00 with Layla Haddad.
- PersonLayla Haddad, Head of Partnerships, Aven Freight (fictional)
- HistoryFour meetings with your team. The last one was with Omar, 12 days ago.
- Open follow-up"Send the revised pilot scope", promised on that call.
- EmailThread "Pilot scope": Layla wrote last. Subjects only, never bodies.
Read as the key's owner, under your team's access rules. Logged with its purpose.
Context API
Ask for the context, not the rows
One call returns what Ishara knows about a person, a company or a meeting: who they are, how your team knows them, what was said and what is still open. Your agent reads it under the key owner's access, and nothing it reads is used to train a model.
| Ask | Route and tool | What comes back |
|---|---|---|
| Look up a person | POST /v1/people/contextishara_people_context | Who they are, their position and company, and how your team knows them. |
| Look up a company and its team | POST /v1/companies/contextPOST /v1/companies/teamishara_companies_contextishara_company_team | The company's facts, how its team divides, and the people on it. |
| Context for a meeting or an account | POST /v1/context/bundleishara_context_bundle | People, companies, history, open follow-ups, email subjects and deals, in one call. |
| Relationship history | POST /v1/relationships/historyishara_relationship_history | Every earlier meeting with these people, and when the first conversation was. |
| Pre-meeting brief | POST /v1/briefs/getishara_brief_get | The brief Ishara prepared for a meeting, with its document and delivery record. |
| Open follow-ups | POST /v1/followups/openishara_followups_open | Tasks and promises still open with these records, with where each came from. |
One request, one answer your model can use
Name the people and the sections you want. Ishara resolves who they are, reads each section as the person the key belongs to, and returns one document with where every fact came from and what was left out, and why.
- Email context carries subjects, direction and who wrote last. It never carries message bodies.
- Every call is logged with its purpose, so agent reads are told apart from people's.
- An administrator can switch context sharing off for the whole workspace.
The full OpenAPI reference comes with your API access.
curl -X POST "https://<your-ishara-api-host>/v1/context/bundle" \
-H "X-API-Key: $ISHARA_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"attendees": [
{ "email": "layla@example.com", "name": "Layla Haddad" }
],
"sections": ["people", "history", "followups", "mail"]
}'MCP server
Your AI tools, reading Ishara under your rules
The Ishara MCP server gives MCP-compatible AI assistants and coding tools the same context, one tool per read route: people, companies, teams, meeting history, follow-ups, email subjects, deals, briefs and any record or list in your workspace.
It holds one thing, the key you give it. Every tool call is one request to the API with that key, so the API's scopes, limits and request log apply unchanged.
- Give the key
context:readto read, andproposals:proposeto suggest changes. - Only a key that a member deliberately grants
proposals:applycan change a record. - Revoke the key in Settings and its next call is refused.
{
"mcpServers": {
"ishara": {
"command": "node",
"args": ["/path/to/ishara-mcp.mjs"],
"env": { "ISHARA_API_KEY": "<your Ishara API key>" }
}
}
}Agents propose, people approve
An agent suggests the change. A person applies it.
Through MCP or the API, an agent sends a proposal with its reason and evidence. Ishara checks it against your rules and shows the record before and after. Nothing on the record moves until a person applies it in Review.
- ProposeWith a reason and evidence
- PreviewBefore and after, per record
- A person appliesOr rejects, in Review
- On the recordMarked as AI, with its run
Low-risk proposals, such as a note or a task, apply themselves only in a workspace whose administrator switched that on. It is off by default. More on AI you approve before it writes anything.
Object API
Build on your records without a second copy
The same routes serve Companies, People, Deals and every object you define. One key in the X-API-Key header. Writes are idempotent under an Idempotency-Key, so a retried request writes once; an upsert matches on any identity key you name; a batch sends many operations in one request.
| Method | Path | Does |
|---|---|---|
GET | /objects | Every object with its attributes, so a client describes itself |
GET | /objects/:object/records | List records of any object, with search, filters and sort |
POST | /objects/:object/records | Create a record, validated against its field types |
POST | /objects/:object/records/upsert | Create or update, matched on any identity key you name |
GET | /records/:id | One record with its values and list entries |
PATCH | /records/:id | Update values |
DELETE | /records/:id | Archive a record; it stays restorable |
GET | /search | Search across your objects |
GET | /lists/:id/entries | The records on a list, with their list values |
POST | /records/:id/notes | Add a note; tasks and logged interactions work the same way |
POST | /batch | Many operations in one request, optionally all or nothing |
POST | /proposals | Propose changes for a person to approve |
GET | /events | Pull events by cursor, for systems that prefer to ask |
POST | /subscriptions | Send events to your endpoint, signed |
Keys are created in Settings and shown once. Each has scopes per resource (read companies, write notes), a rate limit, an expiry by default and overlapping rotation. An integration gets its own identity, so its key outlives whoever issued it. Calls run as the key's owner, so validation and access rules apply exactly as they do in the app.
Webhooks
Every change reaches your systems, signed
A record changes and every subscribed endpoint hears about it: signed with HMAC-SHA256 over the body and a timestamp, retried with growing gaps, replayable from the delivery log, and available to pull by cursor.
- EventA record changes
- Fan-outOne delivery per endpoint
- RetriesOnly if a delivery fails
- DeliveredSigned and timestamped
- ReplayFrom the delivery log
Secrets are shown once and rotate at any time. Endpoints are https only. A webhook is also one action an automation can take, and the integrations page shows what connects without code.
Under your rules
The API is the boundary
A key acts as its owner
It sees the records, threads and calls that person can see, nothing more, narrowed further by its scopes.
Every read is recorded
Each Context API call is logged with its purpose. Each Object API call is logged too.
Never used for training
Your private context is supplied at the moment of a request and is never used to train models.
You hold the switch
Revoke a key, rotate it, or switch context sharing off for the workspace. Security details are on the security page.
The connected view
One connected view. Permissioned access.
Bring workspace context to your application through API and MCP, under the identity and access rules described above.
Explore the productFrequently asked questions
Is our data used to train AI models?
No. Your private context is supplied to a model at the moment of a request, under the key owner's access, and is never used to train models.
Which agents can connect to Ishara?
MCP-compatible AI assistants and coding tools connect through the Ishara MCP server, and any system that can send an HTTPS request can call the API. Each one uses a key your workspace issues, with the scopes you choose.
Does an agent read our email?
Through the Context API and MCP it reads who wrote, when and the subject of each thread on the records it asks about. It never receives message bodies.
Can an agent change our records?
Through MCP it proposes. A person applies the proposal in Review, unless a member deliberately gives a key the apply scope. An integration key you give write scopes writes through the Object API as its owner, under the same access rules.
Which plan includes the API?
Free includes read-only API and MCP access, 1,000 reads a month. API keys, webhooks and 50,000 reads a month come with Pro at $12 per seat per month, and Business carries 500,000. Ishara opens in waves from the waiting list, and a work email reserves 5,000 credits ($50).
Can we switch agent access off?
Yes. Revoke or rotate any key in Settings, and an administrator can switch context sharing off for the whole workspace.
Give your agents context they can trust.
Join the waiting list for API and MCP access, or email our team about your use case.
Early access in waves · A work email reserves 5,000 credits ($50) · Arabic and English