Skip to content
DaneshyarDocs
Sign in
  • Introduction
  • Quickstart
  • API keys
  • Authentication
  • Apps, workspaces, resources
  • Ingestion
  • Chat and sessions
  • Citations
  • Skills
  • Conventions
  • Workspaces
  • Resources
  • Chat
  • Skills
  • Errors
  • Customer support assistant
  • Internal knowledge base
  • Documentation chatbot
  • Embedded widgetOn the roadmap: Soon
  • TypeScript SDKOn the roadmap: Soon
  1. Docs
  2. Getting started

Introduction

A REST API for uploading documents and asking questions that are answered from them, with citations.

The Daneshyar API lets you upload documents into a workspace and then ask questions that are answered from those documents — with citations pointing back to the passage each claim came from. It is the same retrieval engine the Daneshyar console runs on, exposed for your own product.

Every request is authenticated with a single API key that identifies one of your apps. There is no app id in any URL: the key already names the app, so paths start at the workspace.

Your API key authenticates as the app's owner and can create and delete workspaces, upload and delete resources, and read every stored file. Call this API from your server only — never from a browser, a mobile app, or anywhere a user could read the key.

What you can build

The API is deliberately small. With four endpoints you can:

  • Answer support questions from your own help centre, with a link to the source article.
  • Give each customer, patient or student their own workspace, so answers never cross between them.
  • Build an internal assistant over policy documents, contracts or research that never leaves your account.
  • Add a grounded question box to a product you already have, without building retrieval yourself.

How the pieces fit

Four objects, in a strict hierarchy:

  • App — Your integration. It owns exactly one API key, and every workspace below it. You create apps in the console, not through this API.
  • Workspace — A collection of documents that get answered together. This is the unit of separation — a question asked in one workspace can never retrieve from another.
  • Resource — One uploaded document. It goes through an ingestion pipeline that extracts its text, splits it and embeds it before it can be answered from.
  • Chat — A question against one workspace. The server retrieves the closest passages from that workspace's ready resources, answers from them, and returns the citations.

The shape of your workspaces is the most important design decision you will make with this API — one per customer, per team, or per topic. Read the concepts page before you commit to one.

Base URL

Every path in this reference is relative to this base. It is the same host the console talks to, on a separate versioned namespace:

https://api.daneshyar.info/api/v1

Paths carry a trailing slash. The server redirects the slashless form, which turns a POST into a GET and silently drops your body — so always include it.

You will not find an app id anywhere in these paths. If you are porting code from the console's own API, that is the main difference: the key identifies the app, so /v1/workspaces/ already means “the workspaces of the app this key belongs to”.

Where to go next

QuickstartUpload a document and get your first cited answer, in four requests.AuthenticationOne header on every request, and what happens when it's wrong.Apps, workspaces, resourcesThe three objects everything else is built on.ChatAsk a question and get an answer grounded in the workspace's documents.

There is also a generated OpenAPI schema at /api/v1/schema/, with Swagger UI at /api/v1/docs/. It is authoritative on field types; this site is where the reasoning lives.

NextQuickstart

On this page

  • What you can build
  • How the pieces fit
  • Base URL
  • Where to go next

Every example on this site runs against the live API. If one doesn't, tell us — that's a bug in the docs.

ServicesAboutTalk to us