Everything the MCP does, over HTTP with an API key, for a product with users of its own.
One door
The API is the same service the MCP speaks to, over HTTP with an API key. It is for a product with users of its own: you register an organisation, create your users as clients under your own ids, place orders in their name, and get a webhook when a document lands. The catalog, the standards and the prices are the ones an agent sees.
The order flow
One order, from key to document.
Create a client
One call with your own id for the user, their birth date, country and language, and the consent you obtained. No sign-in of their own.
Place an order
Post a brief to the protocol's endpoint in the client's name, naming one or more professions. The answer is the order with its status, or a refusal that says why.
Delivery by webhook
When a professional delivers, we call your webhook with the order's id and status, signed with your secret, and retry until you answer.
Read the document
Fetch the order. The document is one markdown part per profession under fixed headings, ready to show or to hand to an agent.
Briefs and standards
Every brief follows a schema built from published standards, and the schema is the contract: what it accepts is what a professional can work with. The same example brief runs in our tests and is shown on every order endpoint's reference page. The health declaration is part of it, and so is the client's consent, given once on the account.
How it refuses
A refused call says why and whose fault it is. A malformed brief answers 400 with the field. A client without the health data notice agreed answers 403. A balance too low answers 402 with what is available and what is needed. An order the rules refuse is stored as refused with its reason, and costs nothing. The order's status is queued, assigned, reviewed or refused, and nothing else.
Testing
A test environment runs the same code with test payments, so a whole loop can be run without spending: create a client, place an order, have a professional claim and deliver it, receive the webhook. Write to us for a test key.
Example documents
Each is a complete document as it comes back, one markdown part per profession under its headings.
A training plan
A real one, written by one of our professionals and anonymised, is coming.
An eating plan
A real one, written by one of our professionals and anonymised, is coming.
An evaluation
A real one, written by one of our professionals and anonymised, is coming.
A review of a plan
A real one, written by one of our professionals and anonymised, is coming.
Every endpoint, with a complete example
Every endpoint, grouped in the menu to the left, each with a complete example request, the example input and both schemas. For an agent, the whole API is one address.
For your agent. Paste this address into it, and it reads the whole API: every endpoint, its fields, its example.
https://caremcp.com/openapi.json
GET /api/public/catalog What can be ordered: the protocols, the professions with what each answers and requires, every standard with its source, the prices and the bundles.
POST /api/public/clients/sign-up A client account by email and password. The page uses Apple or Google instead; this is the API's way.
POST /api/public/clients/sign-in A session for a client with an email and password.
POST /api/public/professionals/apply A professional applies: the account is made and signed in, and the pool opens once we have approved it.
POST /api/public/professionals/sign-in A session for a professional.
POST /api/public/organisations/sign-up An organisation account: a company whose pot pays for its clients.
POST /api/public/organisations/sign-in A session for an organisation.
POST /api/public/contact A message to us from the contact page: who, how to answer, what it is about. It arrives as mail and a person answers.
POST /api/public/professionals/interest An application to write for Care MCP from the apply page: who, how to reach them, why, what they are certified in and what else they have studied. It arrives as mail; we vet it and answer.
POST /api/public/sign-out Ends the session the bearer names. Without one, nothing happens.
GET /api/client/me The signed-in client.
PUT /api/client/me Birth date, location, language, email, and the health data notice agreed to. The rules read the first three on every order; no order is placed until the notice is agreed.
DELETE /api/client/me Deletes the account: the email, birth date and sign-ins are erased, every agent's access revoked, every order's brief and document replaced by nothing, an open order refused. Charges and receipts stay for the books and carry no name.
GET /api/client/balance The pot: credits, charged, reserved by open orders, available. A client an organisation pays for sees only what is available.
GET /api/client/statement Every deposit and every delivered order with its price, newest first.
GET /api/client/deposits The deposits paid through the provider, each with its receipt: net, tax and total in the client's currency.
POST /api/client/deposits Starts a deposit with the payment provider and answers the page to pay on, with the tax added for the client's country. The pot is credited the net amount when the provider confirms; the receipt goes by mail.
GET /api/client/receipts The provider's page with the client's receipts, when the provider has one; null otherwise, and the receipts are in the deposits.
GET /api/client/orders Every order, newest first, with the review once there is one.
GET /api/client/orders/:id One order and its review. This is the page the mail links to.
POST /api/client/orders/plan A plan for the period ahead from a professional who has read the client's SMART goals, health context and recent logs: a FITT-VP training plan from a personal trainer, an eating plan from a nutrition coach.
POST /api/client/orders/evaluate A professional's reading of the period that passed: the session-RPE log, the Hooper index and the food record against the SMART goals and the plan; adherence, load, wellbeing, each goal's status, what went well, what to change, what comes next.
POST /api/client/orders/review-plan A professional's review of a plan the client's agent wrote, in the profession's own plan standard: a verdict, findings with what to change, and what the plan must avoid.
GET /api/client/grants The agents allowed to act for the client, by the name each gave when it registered.
DELETE /api/client/grants/:oauthClientId Revokes every token that agent holds. It has to be allowed again to continue.
GET /api/org/me The organisation.
PUT /api/org/me Name, email, country and VAT number for the receipt. A VAT number of the organisation's own EU country, outside Sweden, makes its deposits reverse charged. The currency is fixed.
GET /api/org/balance The pot: credits, charged, reserved by the clients' open orders, available.
GET /api/org/statement Every deposit and every delivered order with its price and the client it was for, newest first.
GET /api/org/deposits The deposits paid through the provider, each with its receipt: net, tax and total in the organisation's currency.
POST /api/org/deposits Starts a deposit with the payment provider and answers the page to pay on, with the tax added for the organisation's country and VAT number. The pot is credited the net amount when the provider confirms; the receipt goes by mail.
GET /api/org/receipts The provider's page with the organisation's receipts, when the provider has one; null otherwise, and the receipts are in the deposits.
GET /api/org/keys The API keys by prefix, never the key.
POST /api/org/keys A new API key, shown once. A key cannot make keys.
DELETE /api/org/keys/:id Revokes a key. Calls with it answer 401 from now on.
GET /api/org/webhook The webhook, when one is set.
PUT /api/org/webhook Sets or replaces the webhook. The secret that signs every delivery is shown here and derived from the id, so replacing the URL keeps it.
DELETE /api/org/webhook Removes the webhook and its deliveries.
GET /api/org/webhook/deliveries What has been sent to the webhook, newest first: attempts, the last status, when the next try is due.
GET /api/org/clients The organisation's clients, newest first.
POST /api/org/clients A client under the organisation's own reference, with what the rules need. No sign-in of their own.
GET /api/org/clients/:id One client of the organisation, by our id.
PUT /api/org/clients/:id Birth date, location, language of a client.
DELETE /api/org/clients/:id Deletes the client: the reference, birth date and every order's brief and document are erased, an open order refused. Charges stay for the books.
GET /api/org/clients/:id/orders A client's orders with status and price, never the review.
GET /api/org/clients/:id/orders/:orderId One order of a client, status and price, never the review.
POST /api/org/clients/:id/orders/plan A plan for the period ahead from a professional who has read the client's SMART goals, health context and recent logs: a FITT-VP training plan from a personal trainer, an eating plan from a nutrition coach. Placed on the client's behalf, charged to the organisation's pot.
POST /api/org/clients/:id/orders/evaluate A professional's reading of the period that passed: the session-RPE log, the Hooper index and the food record against the SMART goals and the plan; adherence, load, wellbeing, each goal's status, what went well, what to change, what comes next. Placed on the client's behalf, charged to the organisation's pot.
POST /api/org/clients/:id/orders/review-plan A professional's review of a plan the client's agent wrote, in the profession's own plan standard: a verdict, findings with what to change, and what the plan must avoid. Placed on the client's behalf, charged to the organisation's pot.
GET /api/pro/me The signed-in professional.
PUT /api/pro/me Name, location, languages, professions, credential countries, and the active switch. Professions and location change what the pool shows.
GET /api/pro/pool Orders waiting that this professional may take: every profession named held, active, approved, credentialed where they live, and not reserved for someone else. Oldest first.
POST /api/pro/pool/:id/claim Takes an order from the pool. The first claim wins; a second answers that it is taken.
GET /api/pro/work The orders this professional has claimed and not yet submitted, oldest first.
GET /api/pro/work/:id One claimed order: the brief whole, the screening, an age and a language.
POST /api/pro/work/:id/release Puts a claimed order back in the pool. The draft is kept for whoever claims it next; the release is counted.
GET /api/pro/work/:id/draft The draft so far, one markdown per profession, and the headings each part must carry.
PUT /api/pro/work/:id/draft Saves one part of the draft. Nothing is checked; the draft is the professional's own.
POST /api/pro/work/:id/validate Checks one part against its standard's headings and the review rules, and answers every finding with where it is. Changes nothing.
POST /api/pro/work/:id/submit Submits the review, one part per profession the order names. Every part is checked; a finding refuses the whole and nothing is delivered. Delivered, the pot is charged, the earning is booked and the client is told.
GET /api/pro/earnings Every earning and what is owed, not yet invoiced. An employee has none and is answered 403.
GET /api/pro/payouts The invoices to us, and whether each is paid. An employee has none and is answered 403.
POST /api/pro/payouts Invoices us for everything owed. The earnings move onto the payout; nothing owed answers that nothing is. An employee is answered 403.
POST /api/operator/credit Credits a pot by hand, in the payer's currency, with a reference to the invoice or the reason. Not a sale: it is outside the tax export.
GET /api/operator/tax Every deposit paid from one date up to and including another, one line per receipt with net, VAT and total, a summary per currency and basis, and the same as CSV for the bookkeeping.
POST /api/operator/payouts/:id/paid We have paid the professional's invoice.
GET /api/operator/professionals Every professional, approved or waiting.
POST /api/operator/professionals/:id/approve Opens the pool to a professional we have vetted, as a contractor who earns per document or an employee on salary who earns nothing here. Approving again changes the engagement.
GET /api/operator/organisations Every organisation.
GET /api/operator/orders Every order by status, with money and who has it, never the brief or the review.
GET /api/operator/health Counts: clients, professionals, organisations, orders by status, webhook deliveries waiting.
POST /api/operator/noop Does nothing. Proves the token.