---
description: Environment split — websites always use remote API; dashboards use local API in dev and remote after deploy; coordinate backend + dashboard releases.
alwaysApply: true
---

# Backend ↔ dashboards ↔ websites

## Who talks to which API

| Client | Local development | After deploy (production) |
|--------|-------------------|---------------------------|
| **Business websites** (storefronts) | Still **remote** `https://api.meshkee.com` (or `https://api.{domain}`) | Same remote API |
| **Dashboards** (manage / business / customer) | **Local** backend (`localhost`) | **Remote** `https://api.meshkee.com` |

Websites never depend on a developer’s local API. Dashboards do during local work.

## Release coordination

Because deployed dashboards hit the **same** remote backend as production websites:

1. **Dashboard-facing API changes** (routes under auth/CMS/`businesses/:id/...` used by dashboards) must ship **backend + dashboards together** (or backend first only if fully backward-compatible with the currently deployed dashboards).
2. Do **not** deploy a dashboard that requires new backend fields/routes until that backend is live on `api.meshkee.com`.
3. Do **not** deploy a breaking backend change for dashboards until the matching dashboard build is ready to deploy in the same window.
4. **Website-facing** API changes go live for all storefronts as soon as the backend is deployed — keep `docs/website-api/` in sync (see `website-api-docs.mdc`). Prefer additive/backward-compatible changes when old websites may still be out.

## Practical order

```text
Compatible API add  →  deploy backend  →  deploy dashboards (can use new APIs)
Breaking API change →  deploy backend + dashboards in one coordinated release
Website-only API    →  deploy backend (+ update website docs); websites pick it up from remote
```

Local dashboard work: run local backend; point dashboard env at local API. After merge/deploy, dashboards use remote API again.