Nexus GatewayOne website key gives your backend access to one restaurant business. Menu, order and status requests also name the connection (location and register) they are for. Connection discovery and webhook management apply to the tenant as a whole.
Send the key with every request
Authorization: Bearer YOUR_WEBSITE_KEY
Content-Type: application/jsonSend the Authorization header on every connection discovery, menu, order, status and webhook management request, and Content-Type when the request has a JSON body. All production tenants use the same HTTPS base URL: https://website.api.pionier.ro. Your website key identifies your tenant; the connection ID selects its point of sale.
| Key | Who uses it | What it can do |
|---|---|---|
| Website key | Your backend | List connections, read menus, submit orders, read status, request eligible cancellations, report delivery/refund outcomes and manage webhooks, including signing-secret rotation and failed-delivery retries. |
| Publisher key | Nexus Retail | Publish menus. You won’t need it, and it doesn’t work as a website key. |
A missing, wrong or revoked key returns 401. There is no token refresh flow: a key works until Nexus replaces or revokes it. Nexus issues website keys; the restaurant can’t see or create them in Retail Admin.
Webhook management uses this same website key, with no connection ID, even before any POS is enabled. The separate webhook signing secret verifies incoming callbacks; it does not authenticate API requests. Replacing your website key does not change the webhook signing secret.
Keep the key on your server
Store the key in environment configuration or a secret manager. It must never reach a browser, mobile app, URL, log, analytics event or source repository. Your website talks to your backend; your backend talks to Nexus.
Your backend is also the only place that may mark an order paid_online, after your payment provider confirms the charge. Nexus trusts that declaration because it comes with your key.
Locations and environments
GET /v1/connections lists the connections enabled for your key, with location and register names. Show these to the customer as locations and use the chosen connection’s ID in menu, order and status requests. When the restaurant enables another location, it appears in this list with the same key.
Menus, product IDs, revisions and order IDs all belong to one connection. Don’t move a cart or an order between connections, even when retrying.
Testing requires an agreed setup. Requests have no test-mode flag. Orders sent to the production gateway with a valid key reach that tenant’s Retail. Coordinate testing with Nexus and the restaurant. If Nexus provides a separate test environment, use its URL and key together.
Always include the connection ID
Every menu, order and status URL contains a connection ID, even if you only have one location.
- No connection ID:
400 connection_required. - An ID that is unknown, disabled or belongs to another business:
404 connection_not_found. - No connections enabled yet:
GET /v1/connectionsreturns{"connections": []}. Keep checkout disabled until the restaurant enables one.
No order is created in any of these cases.
Replace a key
Ask Nexus for a new key, update your backend secret and check that you can read a menu. The old key stops working immediately for every location; menus, connection IDs and order IDs stay the same. The restaurant can disable a single location without affecting the others, and re-enabling it keeps its connection ID.
These docs and /openapi.json are public and contain only made-up example data.