RepairShopr
ERPConnect AI agents to RepairShopr, the CRM, ticketing, and point of sale platform for repair shops. Agents open tickets against a customer, quote and invoice the work, take payments, and track leads through to the repair.
What This Integration Enables
RepairShopr runs the counter of a repair business, and the object at the centre of it is the ticket, because a repair shop's real product is the answer to "is my laptop ready yet". The ticket carries the device, the fault, the technician, the parts, the labour and the conversation with the customer, and it becomes an estimate, then an invoice, then a payment. This connector follows that whole path. Leads are captured before a customer record exists through Create Lead and worked through List Leads. Customers and contacts are created and patched. Tickets are opened with Create Ticket, moved through the account's own workflow with Update Ticket, billed with Add Ticket Line Item by product reference or as an ad hoc charge, and talked about with Create Ticket Comment. Estimates quote parts and labour before work starts, and Convert Estimate To Invoice turns an accepted quote into an invoice carrying the line items across. Invoices are raised, read and sent with Email Invoice using the account's own email template. Payments are recorded with Create Payment, optionally split across several invoices. Products are searched by name, SKU, UPC code or category and read with per location quantities.
A few details decide whether a flow built here behaves. Ticket priorities are stored with a sort prefix, 0 Urgent, 1 High, 2 Normal, 3 Low, and the priority dropdown shows the plain labels while the service maps them to the stored values, so a flow never has to know about the prefix. Payment amounts are supplied in cents, so 125.00 is entered as 12500, which is the sort of unit convention that is obvious once and dangerous forever. Ticket IDs are the internal record IDs and are not the same as the customer facing ticket number shown in the RepairShopr UI, so a flow that receives a ticket number from a person has to resolve it rather than pass it through. Ticket statuses and payment methods are read from account settings rather than from a fixed list, because every RepairShopr account defines its own workflow and payment types. RepairShopr enforces a rate limit of 180 requests per minute per IP address, and most list endpoints return 25 records per page, with estimates at 50 and ticket comments at 10.
Two boundaries are worth naming. Tokens carry per resource permissions, so a token can be granted exactly the operations the flows need rather than the whole account, and that is the right way to set this up. And RepairShopr and Syncro share an application core: this connector targets the RepairShopr product on its own subdomain, and the separate SyncroMSP connector targets the MSP product. Picking the wrong one is a common first mistake and an easy one to avoid.
On events, this connector ships no triggers. There is no webhook subscription action here and nothing here creates a FlowRunner trigger. Change detection is a scheduled poll: List Tickets filtered by status, technician and update date, List Invoices filtered by payment state or update date, and List Leads filtered by status. Because ticket comments page at ten by default, a flow reading a conversation should page it explicitly rather than assume the first response is the whole thread.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Web enquiries that become leads before they become customers
Enquiries arrive from a website form, a marketplace listing and the shop's own phone notes. The agent reads them from Google Sheets and the form tool and calls Create Lead for each one, which is the right object because a lead does not require a customer record to exist yet. As leads qualify, the agent checks List Customers with the free text search and the email filter, creates the customer with Create Customer where there is no match, and opens the repair with Create Ticket carrying the subject, problem type, priority and an initial comment. The workshop hears about it in Slack with the ticket subject and priority, so the bench knows what is coming in before it arrives at the counter.
Quotes that turn into invoices without being retyped
A technician diagnoses a repair and the shop needs approval before ordering the part. The agent calls Create Estimate with the parts and labour, resolving the parts through List Products so the SKUs and prices are the catalog's rather than a guess. The estimate goes to the customer. On a schedule, List Estimates filtered to approved surfaces the ones that came back yes, and Convert Estimate To Invoice turns each into an invoice with the line items carried across, linked back to the ticket it came from. Email Invoice sends it using the shop's own template. Where an estimate has been declined, the agent posts an internal comment on the ticket and moves it to the status the account uses for awaiting collection, so no device sits on a shelf without a reason attached to it.
A payment run that reconciles against the right invoices
Card settlements and bank transfers arrive in batches. The agent reads them from the payment processor, calls List Invoices filtered by payment state, and matches each settlement to the balances it covers. Because Create Payment accepts an amount in cents and can be split across several invoices, a single transfer covering three jobs for one business customer is recorded as one payment applied correctly rather than three separate approximations. List Payments is read first so a settlement already applied is not applied twice. The reconciled set is written to QuickBooks Online, and any settlement that does not resolve to a balance is raised as an automation exception rather than assigned to the nearest plausible invoice.
Human-in-Loop Highlight
Create Ticket Comment is the gate, and it is the gate because of one parameter. The action posts a public or internal comment, optionally with an SMS to the customer. Public or internal is a single setting on the same operation, and the two outcomes could not be further apart. An internal note is where a technician writes what they actually think about a water damaged board or a customer who has brought the same machine back three times. A public comment is a message the device owner reads, and with the SMS option it also arrives on their phone. There is no unsend. In a repair shop the customer relationship is the whole margin, and the fastest way to lose one is a note that was never meant for them. The wording matters as much as the visibility: "board is toast, they will not like the number" is a fine internal note and a resignation letter as a public one. So the agent drafts and stops. It reads Get Ticket for the current state and line items, and pages List Ticket Comments properly rather than reading the default ten, so it knows what the customer has already been told and does not repeat it. It posts to the counter: "Ticket 8841, MacBook Pro liquid damage, Anwar Mahmood. Status moved to Awaiting Customer Response yesterday and the customer has had no message since Monday. Draft public comment plus SMS: 'Hi Anwar, we have completed the diagnostic on your MacBook. The logic board has liquid damage and needs replacement. The estimate is 340 pounds including the board and labour, and I have emailed it to you. Reply here or call the shop and we will get it moving.' The internal thread includes Dev's note that the board is beyond economic repair and he would not recommend it, which I have not included. Send this as public with SMS, send it as public without the SMS, or make it internal only and have someone call instead?" A person answers once, and the comment posts with the visibility they chose. This is the human-in-the-loop moment on a system where the difference between a note and a message to a customer is one field on one call, and the agent has no way to know which side of that line a sentence belongs on.
Agent Capabilities
27 actionsCustomers
4- List Customers Returns customers with free text search and name, business and email filters, paged. This is the resolution read that runs before any customer is created.
- Get Customer Returns the full customer record by ID, including address, portal URL and custom properties.
- Create Customer Adds an individual or business customer with contact details and communication preferences.
- Update Customer Patches an existing customer, sending only the fields you supply.
Contacts
2- List Contacts Returns contacts, optionally scoped to one customer.
- Create Contact Adds a contact under an existing customer account.
Tickets
7- List Tickets Returns the ticket queue with customer, contact, status, technician and date filters. Filtered on update date, this is the polling cursor that stands in for the events this connector does not receive.
- Get Ticket Returns full ticket detail, including comments, attachments, line items, assets and timers.
- Create Ticket Opens a repair ticket with subject, problem type, priority, assignee and an initial comment. Priorities are stored with a sort prefix and the plain labels are mapped for you.
- Update Ticket Moves a ticket through the workflow, reassigns it or changes its due date. Statuses come from the account's own settings, because every RepairShopr account defines its own workflow.
- List Ticket Comments Returns the comment thread with sorting, date filters and body format selection. It pages at ten by default, so a flow that needs the whole conversation pages it explicitly.
- Create Ticket Comment Posts a public or internal comment, optionally with an SMS to the customer. Public and internal are the same call with a different setting, and the public path reaches the device owner and cannot be recalled.
- Add Ticket Line Item Bills parts and labour on a ticket, by product reference or as an ad hoc charge.
Invoices
4- List Invoices Returns invoices filtered by payment state, ticket or update date.
- Get Invoice Returns invoice detail with totals, tax, balance due, line items and the PDF URL.
- Create Invoice Raises an invoice with line items and an optional link back to a ticket.
- Email Invoice Sends an existing invoice to the customer using the account's email template. This reaches the customer, so it belongs downstream of a decision.
Estimates
3- List Estimates Returns estimates with approved and declined filtering, paged at fifty by default.
- Create Estimate Quotes parts and labour before work starts, optionally linked to a ticket.
- Convert Estimate To Invoice Turns an accepted quote into an invoice, carrying the line items across so nothing is retyped.
Products
3- List Products Searches the parts and inventory catalog by name, SKU, UPC code or category.
- Get Product Returns product detail with pricing, stock levels, per location quantities and photos.
- Create Product Adds a catalog item with pricing, stock tracking and serialization settings.
Payments
2- List Payments Returns payment history with amounts, methods and the invoices they were applied to. This read runs before a payment is recorded, so a settlement is not applied twice.
- Create Payment Records a payment, optionally split across several invoices. Amounts are supplied in cents, so 125.00 is entered as 12500.
Leads
2- List Leads Returns the lead pipeline filtered by status, assignee or ticket state.
- Create Lead Captures an inbound enquiry before a customer record exists, which is what keeps a half qualified web form out of the customer register.
Frequently Asked Questions
What can FlowRunner do with RepairShopr?
FlowRunner agents can run List Customers, Get Customer, and Create Customer in RepairShopr, plus 24 more actions.
Does connecting RepairShopr to FlowRunner require OAuth?
No. RepairShopr connects to FlowRunner with an API key, no OAuth flow required.
Can RepairShopr trigger a FlowRunner workflow automatically?
RepairShopr doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with RepairShopr
$100 in credits. No card required. Connect in minutes.