Delete a sandbox, or archive a real restaurant
Partner key + restaurant key.
- A sandbox is deleted for good (
result: "deleted"), together with its keys. A secondDELETEwith the same restaurant key therefore gives401. Confirm withGET /partner/restaurantsthat the slug is gone. - A real restaurant is never deleted. It is archived (
result: "archived"): turned off and closed in/api/v1, while orders and accounting records are kept. Its webhooks are paused. The restaurant keys keep working against the partner API, so you can still read the restaurant, revoke keys and delete webhooks. Only LettBestilt can restore it. Archiving is idempotent: an archived restaurant gives200again.
At most 10 per hour per partner key.
Authentication
The partner key, sent as Authorization: Bearer lbp_test_…. Created in the partner portal under Partner key. It belongs to the partner, not to a restaurant, and only works against /api/v1/partner. Server to server only: a request with an Origin header is rejected with 403 FORBIDDEN. A test key sees and creates only sandboxes; live partner keys are not available yet. A revoked key, a restaurant key (lbs_…) here, or a suspended or archived partner returns 401 UNAUTHORIZED; an expired key returns 401 KEY_EXPIRED.
The restaurant’s own key (lbs_test_… or lbs_live_…), sent in X-LettBestilt-Restaurant-Key together with the partner key for calls about one restaurant. The key must have full access (scope *, otherwise 403 INSUFFICIENT_SCOPE), belong to a restaurant the partner owns, and be in the same environment as the partner key (otherwise 401 UNAUTHORIZED). A slug that does not exist, belongs to another partner or does not match the key always gives the same 404 RESTAURANT_NOT_FOUND. Older keys without an environment in the prefix (lbs_<random>) are not accepted here; rotate them in the partner portal.
Path parameters
The restaurant’s slug. Must match the restaurant key in X-LettBestilt-Restaurant-Key.