Developer API and company API keys

Beyond connecting interactive AI clients, Memocore lets you plug your team's memory into your own product, chatbot or agent over an API. The idea: give your product a memory without building a retrieval pipeline. Key points: - The API is read-only: your product can search and read a project's memories, but the memory is filled by you and your connected assistants, not written through the API. - Search by meaning is built in, and it is real semantic search, not keyword matching under a nicer name. Your query is turned into an embedding - a vector representing what it means - and matched against the embeddings Memocore keeps for your memories; that semantic ranking is then fused with a keyword ranking over the same query, so a memo that both sides find comes out on top. In practice a memory surfaces even when the question shares none of its words. - You send a query and get back only the few relevant memos, rather than stuffing your whole knowledge base into every prompt. That cuts token cost (a few hundred tokens instead of thousands) and keeps one source of truth shared between your product and your assistants. - No vector database, embedding pipeline, fine-tuning or re-indexing to manage - the embeddings are built and kept up to date on our side. You fill a project and query it. Company API keys: - A company owner can mint read-only API keys scoped to a chosen set of the company's projects. - The raw key is shown once when created; store it safely. Only a hint is kept afterward, and usage (last used) is tracked. - This lets external systems query company memory without an interactive AI client. - There is no limit on how many keys a company can mint, and API calls are not metered or billed. The team subscription has to be active for a key to work. Rate limits. A key may make up to 100 requests per second; go over that and the call answers 429, so retry a moment later. Search-by-meaning has its own, separate burst allowance of 50 searches per second: exceeding it never fails the call - the search quietly falls back to keyword ranking for that request and still returns results, so a client that hammers search may notice recall getting slightly worse rather than an error. The same happens if the team's monthly search budget is used up. The endpoints. Every call authenticates with the key in a header - Authorization: Bearer mc_ck_... - and only ever sees the projects that key is scoped to. There are three: 1. GET /api/v1/memos - search or list memos. - query: leave it out to list newest first; pass it to rank memos by relevance to it. One plain string is all you send - it drives both halves of the search at once, the embedding-based meaning side and the keyword side - so there is no separate keyword parameter to fill in. - tags: only memos carrying ALL of these tag ids. - exclude_tags: leave out memos carrying ANY of these tag ids. Combines with tags - tags [task] + exclude_tags [done] returns the tasks that are not finished yet. - archived: pass true to look in deleted-but-not-yet-erased memos instead. - limit (default 30, max 90) and skip for paging. - Returns { items, count }: items already in relevance order (newest-first when there is no query), and count as the total number of matches, for paging. - Each item carries: id, title, preview, has_files, tags as [{ id, name }], project and company as { id, name }, who last updated it, its share access and its created/updated dates. Ids come back resolved to names because a key holder has no endpoint to look them up. Full content lives behind the next endpoint. 2. GET /api/v1/memos/:id - one memo in full: the same fields plus content, meta and its file list. Returns 404 for anything outside the key's projects, so an id from elsewhere reveals nothing. 3. GET /api/v1/tags - search or list the tags across the key's projects. Takes query, limit and skip. Use it to resolve a tag name to the id that the memos endpoint expects. A typical flow: search /api/v1/memos with the user's question, then fetch the one or two ids that matter with /api/v1/memos/:id. Over MCP (what a connected AI client uses) the search tool takes two required inputs instead of one: query, a natural-language description of what is being looked for (max 400 chars), and keywords, a list of 1-12 distinctive terms - names, ids, jargon - written as two views of the same need. Optional: scope (omit for everything the caller can access, "private", or a project id), company (a company id), tags, exclude_tags, archived, limit (max 50, default 20) and skip. It returns items in the same shape as the API, plus a recommendation - a plain-language verdict on how solid the results are, which the assistant is told to read before trusting them. Typical uses: customer-support bots answering from your docs, internal copilots scoped to the right project, retrieval for agents that need shared memory, and drop-in memory for any AI system that can make an HTTP request.