📋 Prerequisites

Before you call the Fodista Public API, complete the following:

1) Confirm your Base URL

Identify the correct base URL for your environment

Production: https://new-fodista

Your tenant: replace with your live hostname (e.g., https://yourbrand.fodista.com)

Keep your base URL consistent across all requests. All endpoints in these docs are relative to this URL.

2) Create an Access Token in Fodista Back Office

You’ll generate a token on the Public API Access document. This token defines your scopes and data boundaries.

Steps (Back Office)

Sign in to Fodista Back Office with an account that can manage integrations.

Search for: Public API Access.

Click New to create a record.

Name your integration (e.g., “Storefront — Production”).

Scopes: select one or more of:

Invoice History — read POS invoice summaries.

Public Menu — read categories and products (use visibility=public).

Online Ordering — carts & checkout (use visibility=online).

Data Access (recommended):

Restaurant Brand / Branch: select the brand/branch the token is allowed to access.

Online Store: if you’ll use ordering, select the exact store this token may operate on.

Network Allowlisting (strongly recommended):

Whitelisted IPs: add fixed IPs that are allowed to call this token.

Examples: 198.51.100.0/24, 198.51.100.8

Whitelisted Domains (Origins): add HTTPS origins that can use this token from browsers.

Examples:

https://storefront.example.com

https://staging.storefront.example.com

If you use a CDN (e.g., reverse proxy), prefer domain allowlisting for browser apps and IP allowlisting for server-to-server.

Save the document.

Click Show Token.

10.

Copy the generated token and store it securely (treat it like a password).

3) Store the Token Securely

Configure your runtime to pass the token on every request:

Environment variables (server-to-server):

App config (frontend): never hardcode tokens in client code for public sites. Use a secure backend to proxy requests, or issue short-lived tokens if your architecture requires direct calls.

4) Call the API with the Required Header

Use the X-Access-Token header. Legacy posting of access_token in the body is supported but discouraged.

5) Scope–Visibility Checklist

Public Menu scope → always send visibility=public on menu endpoints.

Online Ordering scope → use visibility=online on menu endpoints and all ordering endpoints (add-to-cart, update-cart-item, get-cart-details, etc.).

Invoice History scope → supply from_date and to_date (ISO 8601).

Accepts YYYY-MM-DD or YYYY-MM-DDTHH:MM:SS (inclusive range).

Example: Invoice Export

6) Expected Responses & Errors

200 — Success (payload shape varies by endpoint; see OpenAPI schemas).

401 — Missing/invalid token (check header, rotation, or allowlists).

403 — Token is valid but the scope/data is not permitted (check scopes, visibility, brand/branch/store).

404 — Resource not found (e.g., coordinates did not resolve in get-address).

7) Security Notes

Treat tokens as credentials. Do not embed them in public frontends or logs.

Use IP allowlists for server-to-server integrations.

Use domain (origin) allowlists for browser apps; keep HTTPS and HSTS enabled.

Prefer least privilege: assign only the scopes your integration needs.

Rotate tokens periodically and after personnel changes.

1) Confirm your Base URL#

2) Create an Access Token in Fodista Back Office#

Steps (Back Office)#

3) Store the Token Securely#

4) Call the API with the Required Header#

5) Scope–Visibility Checklist#

Example: Invoice Export#

6) Expected Responses & Errors#

7) Security Notes#