Skip to main content
The muveya public API is a REST surface under /v1 for server-side integrations: an ERP or purchasing system, a BI tool, a spreadsheet job, an internal dashboard. It authenticates with an API key that belongs to exactly one dental clinic, and it reads the same data your team works with in the console. The API is read-only, with one exception: POST /v1/analytics/exports, which asks muveya to build a CSV file of the management briefing. Nothing you call on /v1 creates, changes or deletes an order, a box, a stock movement, a member or a catalog item.

​
Base URL

Every public path starts with /v1, so your first call is https://api.muveya.com/v1/me.

​
Authentication in one line

The key is sent as a bearer token on every request. It is bound to one dental clinic on the server: no path, query parameter or header ever names a dental clinic, so a key can only read its own. See Authentication for how to get a key and keep it safe.

​
Console words and API words

The console and the API describe the same things with different words. Keep both in mind when you map API data to what people see on screen.

​
What /v1 covers

Every scope is explained on Scopes. The request and response of each operation are documented in the Endpoints group of this tab.

​
What /v1 does not do

  • It does not create or change anything in your operation: orders, approvals, picking, dispatch, delivery, receipt, stock receipts, use, moves, corrections, counts, catalog edits and team changes are done in the console, and some stock tasks from WhatsApp.
  • It does not create or revoke API keys. See Authentication.
  • It does not send events to your systems. There are no webhooks yet; see Webhooks for how to poll instead.
  • It never returns order totals or patient references (see Data that is left out).

​
Conventions

JSON everywhere. Successful responses are application/json. Errors are application/problem+json documents with a stable code (see Errors). Field names are English camelCase and enum values are English lowercase words such as pending_approval; metric keys are uppercase, such as LOW_STOCK. None of them changes with the language. Opaque ids. Every id is a string. Compare ids as strings and never parse them or build them yourself. An id that belongs to another dental clinic behaves exactly like an id that does not exist: the answer is a 404. Absent, not null. An optional field that has no value, or that your key is not allowed to see, is left out of the response. It is not sent as null or as 0. The exceptions are three analytics fields: value (of a metric or a briefing figure) and averageHours (of a cycle-time stage) are null when there was no sample to measure, and maxAgeHours is null for the open-ended approval-backlog band. Timestamps in UTC. Dates and times are ISO 8601 strings in UTC with a Z suffix, for example 2026-09-15T13:45:00.000Z. Analytics reports state "timezone": "UTC". Time windows you send (from, to) are ISO 8601 too. Money in minor units. An amount is an integer in the minor unit of its currency (cents for USD) and always travels with currency, an ISO 4217 code: "cost": 1250, "currency": "USD" means 12.50 USD. Money appears only in catalog cost fields and in order line unitCost, and only for a key with catalog.cost:read. Quantities in the item unit. Quantities such as onHand, requestedQty or quantityDelta are integers counted in the item’s unitOfMeasure (unit, box, milliliter and so on). Quantities of different items or units are never added together by the API. Language. Send Accept-Language with en, es or pt (English is the fallback). It changes only text meant for people: the title and detail of an error, the label of each briefing figure, and the labels inside a CSV export. Keys, codes, enum values, numbers and ids stay the same in every language. Request ids. Every response carries an x-request-id header. If you send your own X-Request-Id with a UUID, muveya reuses it; otherwise it generates one. Error bodies repeat it as requestId. Log it on your side and include it when you write to team@muveya.com. Lists. Every list answers { "data": [...], "hasMore": false }, plus nextCursor when there is another page. See Pagination. Rate limits. Every key has its own request budget and every response reports it in headers. See Rate limits. Stability. Inside /v1 changes are additive. See Versioning and the changelog.

​
Data that is left out

The server removes data your key may not see before the response is built. Fields are absent, never masked. An API key is not a team member and it is not limited by location access: it reads every location and warehouse of its dental clinic within its scopes. Grant a key only the scopes the integration needs.

​
How this reference is organized

  • Overview (these pages): authentication, a quickstart, scopes, pagination, rate limits, errors, versioning, exports and webhooks.
  • Endpoints: one page per operation, generated from the muveya OpenAPI contract, in your language. Each page shows the parameters, the response schema, the possible errors and request examples in cURL, JavaScript and Python. The request builder on those pages only prepares a request for you to copy: it never sends it and never stores your key.
The MCP server at https://api.muveya.com/mcp uses OAuth sign-in and authorization for AI assistants. See MCP.

Authentication

Get a key, send it and keep it on your server.

Quickstart

Your first calls with cURL, JavaScript and Python.

Scopes

What each scope lets a key read.

Errors

The problem document and every error code.