Orderry

Orderry runs repair shops, field service teams, auto services and salons, businesses where the same job is a lead, a quote, a work order, a parts list, an invoice and a payment, and where all six live inside one week. The same platform ships under the RO App brand, formerly RemOnline, and this connector serves both: a Product config item picks the API host and everything else is identical. What this integration is actually for is closing the loop between the shop floor and everything around it, because the failure mode in a service business is not that the platform lacks a field, it is that the job progresses and nothing outside the platform finds out.

Agents work the whole cycle. Inquiries capture the lead through Get Inquiries, Create Inquiry and Update Inquiry Status. Estimates quote it through Get Estimates, Create Estimate and Change Estimate Status, and Create Estimate takes order_type_id rather than an estimate specific field name, which is the vendor's own naming and is reproduced verbatim so the call succeeds. Orders carry the work through Get Orders, Get Order, Create Order, Update Order and Update Order Status, with Get Order Items and Add Order Item for the parts and labor lines and Create Order Comment for the running narrative. Get Order Public Page URL returns the shareable customer facing page for a job, which is the single most underrated action here, because it turns a status change into something you can send someone. Bookings are covered through Get Bookings and Create Booking, people and organisations through Get People, Create Person, Update Person, Get Organizations and Create Organization. Invoices are raised and progressed through Get Invoices, Create Invoice and Update Invoice Status, and finance is real: Get Finance Accounts and Get Account Transactions read the accounts and their movements, and Create Transaction posts cash and card payments into them.

The catalog is read only, and it is worth being exact about that. Get Products and Get Services search the catalog, and there is no create, update or delete for a product or a service in this connector. So this integration does not maintain a parts catalog. It reads one, which is the right shape for resolving a part reference before it is added to an order through Add Order Item, and the wrong shape if you were hoping to sync a supplier price list into Orderry from here. Note also that catalog searches and the reference lists expose no page parameter and return their full result set, while ordinary list endpoints return 50 records per page with page and a count in the envelope.

On events, be plain about the distinction. This connector ships no triggers. Orderry does publish a documented webhook catalog covering tasks, inquiries, bookings, orders, estimates, sales, clients, invoices, comments, attachments and logins, with a documented JSON payload, so the events exist. But subscriptions are created only through the web app under Settings, then API, and the public API exposes no subscription endpoint at all, with /v2/webhooks returning 404. There is therefore no action here that registers one and nothing that creates a FlowRunner trigger. If you want those events today, you register a FlowRunner callback endpoint of your choosing by hand in the Orderry web app, which is a configuration you make in Orderry rather than a capability of this connector. Otherwise change detection is a scheduled poll of Get Orders, Get Invoices or Get Inquiries with the date range filters, which every action exposes as a From and a To parameter and assembles into the one or two element ISO 8601 array the API expects. Two more details decide whether writes land: order, estimate, inquiry and invoice statuses are configured per account and each order or estimate type carries its own status set, so a status ID from one type is rejected on a document of another type and should be read from the status dictionaries rather than hardcoded. And Add Order Item requires entity_id, assignee_id, quantity, price, cost, a discount object and a warranty object, with the connector always sending the discount and warranty objects using the vendor's documented defaults when you leave them empty.