Restaurant365 – Gotchas

Bill payments cannot be created through this connector — the create operation is unsupported. R365's create-payment endpoint requires a header-level locationId, and the unified BillPayment schema has no field to source it from. Mapping the operation without it would either fail with a 422 or silently apply the payment to the wrong location, so it was left unmapped rather than shipped broken. Bill payments can only be read.

Bill payments cannot be updated through the unified update operation — it is unmapped. R365's own PATCH endpoint accepts approvalStatus (approve/reject) and invoiceIds/ creditMemoIds (changing which bills/credit memos the payment is allocated to), not general field updates, so mapping it under the generic unified update would have silently discarded any other field the caller sent. Create is also unmapped — R365's create-payment endpoint requires a locationId the unified schema has no field for. Bill payments can only be read through this connector.

Bill payments cannot be deleted through this connector — the delete operation is unsupported, and there is no workaround. Bill payments can only be read; create, update and delete are all unmapped.

location_id is optional in the unified schema but effectively required by R365 — R365's create-invoice endpoint requires a LocationId. Omitting it on create risks a rejected write rather than a bill created against a default location.

Bills cannot be updated through this connector at all — the update operation is unsupported, not merely limited. R365's own PATCH endpoint accepts only an approvalStatus field (approve/reject), not general field updates, so mapping it under the unified update operation would have silently discarded any other field the caller sent. There is no workaround; bills can only be created and read.

Bills cannot be deleted through this connector — R365's Public API exposes no delete endpoint for AP invoices. There is no soft-delete or status-based workaround; bills can only be created and read.

Restaurant365 does not have a dedicated company info endpoint. This operation returns the first legal entity from the tenant's legal entities list. For multi-entity accounts, use the subsidiaries endpoint to get all legal entities.

location_id is optional in the unified schema but effectively required by R365 — R365's create-credit-memo endpoint requires a LocationId. Omitting it on create risks a rejected write rather than a credit memo created against a default location.

Credit notes cannot be updated through this connector at all — the update operation is unsupported, not merely limited. R365's own PATCH endpoint accepts only an approvalStatus field, and only the value Approved (unlike bills, R365 has no reject path for credit memos) — not general field updates, so mapping it under the unified update operation would have silently discarded any other field the caller sent. There is no workaround; credit notes can only be created and read.

Credit notes cannot be deleted through this connector — R365's Public API exposes no delete endpoint for AP credit memos. There is no soft-delete or status-based workaround; credit notes can only be created and read.

Restaurant365 requires a LocationId on every call to this endpoint — there is no tenant-wide "all locations" mode. A request with no LocationId returns a 400, not an empty or partial result. Pass it via pass_through[LocationId]=<uuid>.

source_type is derived from R365's transaction type field (APInvoice, APCreditMemo, APPayment, JournalEntry); other R365 transaction types pass through unmapped rather than being coerced to the nearest enum value.

line_items is always empty. R365's own documentation shows the details/distribution fields on this endpoint as empty placeholders and never documents their populated shape, so there is currently nothing to map — the transaction total, type and location are populated, but not the underlying GL distribution lines.

Only filter[updated_since] is wired (to R365's ModifiedOnStart). filter[source_type] and filter[source_id] are not — R365 exposes a TransactionTypes filter and no source-id equivalent, so filtering by either currently has no effect rather than narrowing results.

status is always reported as active. R365's location payload does not expose an active/inactive flag, so an inactive or archived location cannot currently be distinguished from an active one through this connector.

Payments cannot be created through this connector — the create operation is unsupported. R365's create-payment endpoint requires a header-level locationId, and the unified Payment schema has no field to source it from. Mapping the operation without it would either fail with a 422 or silently apply the payment to the wrong location, so it was left unmapped rather than shipped broken. Payments can only be read.

Every R365 payment is an accounts-payable (vendor) payment — customer is always null. The counterparty is only available via the deprecated supplier field.

line_items is always empty. R365's own documentation shows the purchase order details field as an empty placeholder and never documents its populated shape, so there is currently nothing to map — the order total, quantity, vendor and location are populated, but not the individual line items.