Restaurant365 – Configuration Guide
Restaurant365 is a cloud ERP built specifically for restaurants, covering accounting, AP automation, inventory, workforce and payroll.
How to obtain Restaurant365 API credentials for your integration
This guide is for you, the Apideck customer building an integration. It covers how Restaurant365 issues API credentials, which of the two R365 contact paths you need, what to include on the request, and what to do with the credentials once they arrive.
Restaurant365 does not use OAuth. There is no app to register, no consent screen, no client ID and no client secret — and no self-service developer signup that hands you credentials. R365 issues credentials as a per-customer grant: a username and password scoped to one specific customer's R365 database, released by R365 Support once both you and that customer have confirmed the request.
That shapes the whole setup, and in one useful way it simplifies it: there is nothing to configure at integration level in Apideck. You do not paste a partner key or a shared secret into the Apideck Dashboard for this connector, because none exists. Your work is to get credentials issued for each customer you onboard, then hand them to whoever creates that customer's connection.
Before you start
- An Apideck account with the Restaurant365 connector enabled for the Accounting API — see the Restaurant365 connector settings in the Apideck Dashboard.
- A Restaurant365 customer to connect to. Credentials are issued against a specific customer's own R365 database, so the request needs a named customer — there is no generic developer account to request instead.
- A named technical contact on your side. R365's documentation asks that you "include a member of the vendor's technical team on any request" — "vendor" here means you, the third party building the integration.
- A short description of the R365 data your integration reads and writes. R365 enables Public API access per customer database, so stating the data set up front saves a round trip on the request (see step 1).
Two different conversations with Restaurant365 — keep them separate
Both paths lead to R365, and it is easy to send the wrong one. They produce different things:
| What you want | Who to contact | What comes out of it |
|---|---|---|
| Credentials for one customer's R365 database — needed for every single connection | The customer's R365 CSM, or R365 Support, through R365's API Credentials Request process (step 1) | A subdomain-scoped username and password for that one customer's database |
| A technology partnership with R365 — R365's branded API-partner ecosystem, "R365 Connect" | R365's partner team: sales@restaurant365.com or (949) 652-7800 | A partnership relationship. It does not issue credentials for any particular customer database |
The important consequence: the per-customer credential request in step 1 happens for every connection regardless of where your partnership conversation stands. A partnership does not pre-authorize your customers' databases, so do not wait on one before starting step 1 for a customer who is ready.
1. Request credentials for a customer's database
Either side can start the request, and R365 confirms with the other before releasing anything. R365 documents both directions:
- The customer starts. They submit the request to R365 Support; "R365 confirms permission and provides credentials directly to the vendor" — that is, directly to you.
- You start. "If the vendor initiates, R365 confirms with the customer before providing credentials."
Either way, include a member of your technical team on the request.
The documented route is R365's API Credentials Request form, which the customer's CSM completes: see R365 Public API, which links the API Credentials Request form. R365 labels that form internal-access only, so expect it to be filled in by the customer or their CSM rather than by you — asking the customer to loop in their CSM is usually the fastest opening move.
If you have no CSM to route through, contact R365 Support directly at support@restaurant365.net or through the R365 Support channels.
This is a human process rather than an automated portal, so treat it as a scheduled step in your onboarding rather than something that resolves while you wait — and ask your R365 contact for an expected timeline so the customer's go-live can be planned around it.
What to include on the request
R365 enables Public API access for one customer database at a time, so it helps to say plainly what the integration will do with it. For reference, this is the R365 Public API data the connector reads and writes:
| R365 data | Endpoint the connector calls | How the connector uses it |
|---|---|---|
| AP invoices | /public/v1/accounting/accounts-payable/invoices | Read and create |
| AP credit memos | /public/v1/accounting/accounts-payable/credit-memos | Read and create |
| Journal entries | /public/v1/accounting/journal-entries | Create |
| AP payments | /public/v1/accounting/accounts-payable/payments | Read |
| GL accounts | /public/v1/accounting/gl-accounts | Read |
| Bank accounts | /public/v1/accounting/general-ledger/bank-accounts | Read |
| GL transactions | /public/v1/accounting/transactions | Read |
| Vendors | /public/v1/inventory/vendors | Read |
| Purchase orders | /public/v1/inventory/purchase-orders | Read |
| Legal entities | /public/v1/core/legal-entities | Read |
| Locations | /public/v1/core/locations | Read |
Say explicitly that the integration writes as well as reads — it creates AP invoices, AP credit memos, and journal entries. Worth knowing when you plan your own testing: Apideck's connection check calls the vendors list endpoint, so a connection that validates successfully has proven a read, not a write. Exercise a write against the customer's database yourself before go-live.
2. What R365 issues, and what to do with it
R365 hands back credentials for one database. Three values are needed to create the connection:
| Value | Where it comes from |
|---|---|
| Subdomain | The customer's own R365 hostname — the mycompany in https://mycompany.restaurant365.com, as it appears when they are logged in |
| Username | The API username R365 Support issued for that database |
| Password | The API password issued alongside it |
There is no client ID, client secret, or long-lived API token in this set, and nothing here is stored at integration level in Apideck.
You do not implement a token exchange. The connector posts the username and password to R365's authentication endpoint and uses the session bearer token it returns, renewing it on every request. Your side of the work ends at delivering the three values above.
Handing the credentials over
Those three values are entered in the Vault connection settings for that customer's connection — the consumer side of the setup, covered in the connection guide. Two practical notes for the handoff:
- Treat the password as a production credential. It authenticates against the customer's live R365 database, so move it over a channel you would use for any other production secret, and keep your own copy in a secret manager if you are holding it on the customer's behalf.
- Decide who types it in. If R365 sends credentials to you, either pass them to the customer to enter in Vault, or enter them yourself on their behalf. Both work; agreeing which one up front avoids a credential sitting in an inbox.
3. Plan your build around a live customer database
Restaurant365 documents no sandbox or trial environment, and none is referenced anywhere in their Public API docs. Treat this connector as unverified end-to-end until confirmed against a live connection — the workable path in the meantime is a cooperating customer — a mutual customer, or an existing R365 customer willing to sponsor the request in step 1. Line that up first: it is the one prerequisite that gates everything else, and it is worth having before you write code.
Two things follow from it:
- Every connection points at production. The connector's server address is built from the
customer's own subdomain (
https://{subdomain}.restaurant365.com), and there is no environment selector to switch — there is only production. Sequence your testing accordingly: exercise the read endpoints before the write ones, and agree with the customer which records your writes may touch. - Ask R365 about test-environment options when you make your request. Environment policy is R365's to state, and asking explicitly costs nothing — just do not build a plan that assumes a test database will be offered.
4. What repeats for every customer
There is no shared credential that covers multiple customers, so each new R365 customer means:
- A new API Credentials Request for that customer's database (step 1).
- A new set of subdomain, username, and password (step 2).
- A new Vault connection using them.
Steps 1 and 2 are R365's process and the part worth building into your onboarding checklist; step 3 is quick once the credentials exist.
Troubleshooting
You want to try the connector before contacting R365. Not possible for this connector: Apideck holds no shared Restaurant365 credentials, and R365 offers no sandbox. The shortest route to a working connection is a customer already on R365 who will sponsor the credentials request.
You cannot open the API Credentials Request form. Expected — R365 documents it as internal-access only. Ask the customer to have their CSM complete it, or email R365 Support at support@restaurant365.net instead.
You submitted a request and heard nothing back. Credentials come from a human team, not a portal. Follow up through R365 Support, confirm a member of your technical team is on the thread, and ask your contact for an expected timeline. If the customer initiated the request, check with them too — R365 may be waiting on their confirmation, or may have already sent the credentials to a different address on your side.
R365 asks what data your integration needs. Send the endpoint table in step 1 and state that the integration writes as well as reads. Worth saying explicitly: none of this touches customer-invoicing or accounts-receivable data — R365's Public API has no surface for that — even though the table covers more than accounts payable (general ledger, vendors, purchase orders, legal entities, locations, bank accounts).
Credentials work for one customer and not another. Each set is scoped to a single R365 database. A second customer needs its own request — and check the subdomain on the failing connection, since a credential paired with the wrong subdomain fails the same way a wrong password does.
A connection is rejected as soon as it is created. Apideck validates a new Restaurant365 connection by listing vendors, so the credential has to be able to read vendors for that database. Confirm with R365 that Public API access is enabled for the database in question, and check that the credential was issued for the same subdomain that is on the connection.
For anything on the Apideck side of the setup, contact Apideck Support.
Reference
- R365 Public API — the API surface this connector uses, and the API Credentials Request form link
- R365 API Connector — R365's rules on who may request credentials and how R365 confirms with both parties
- R365 Support — support channels for the credentials request
- Restaurant365 Partner Ecosystem — the "R365 Connect" partner program and partner-team contact details
- Restaurant365 connector settings — the connector's page in the Apideck Dashboard