Authentication for Restaurant Owners and Staff

The first version of the app used the Owner model for authentication. In that model, each restaurant belonged to one owner.

Later, some owners managed multiple restaurants or branches, so we introduced the RestaurantGroup model.

• One RestaurantGroup had many restaurants.

After that, we also had cases where one restaurant needed multiple staff accounts with different access scopes (i.e., different permission levels and accessible features). To support that, we introduced the Staff model.

• One Staff can access many restaurants.
• One restaurant can have many staff members.

Deprecation

The Owner and RestaurantGroup authentication paths are deprecated and should be migrated to the Staff model. New integrations must not use the Owner or RestaurantGroup authentication flow.

Migration: Replace any Owner-based authentication with Staff-based authentication. Use the Staff model endpoints documented in the API reference.

Current Recommendation

Use the Staff model for all authentication and access control. Here is how to authenticate as a staff member:

1. Send a POST request to /api/v1/staffs/sign_in with email and password in the request body.
2. The response returns a JWT token and the staff member’s details, including their accessible restaurant IDs.
3. Include the token in the Authorization: Bearer <token> header for subsequent API requests.
4. To scope access to a specific restaurant, include the restaurant ID in the request context as documented in the API reference.