RepairShopr plugin

• The subdomain is half the credential. Pass it when you create the plugin, or store it on the account beside the key. A missing or malformed value fails before a request is sent rather than resolving to a host that does not exist.
• A 401 covers three different problems. Failed to authenticate account means a bad key, a wrong subdomain, or a key that belongs to another account; RepairShopr does not separate them, so the plugin reports one auth error rather than guessing.
• Paging is by page number. Collections answer with their own array plus a meta block carrying total_pages, and next_page is derived from it. Only invoices accepts per_page (at most 25); the others use the account default.
• Sorting names a column and a direction, such as firstname ASC or created_at DESC.
• Products and vendors may carry no meta. Without it the plugin cannot tell whether more pages exist, so next_page is null rather than an invented number. A null there does not mean every record came back: ask for the next page yourself and stop when it comes back empty.
• Money is a string on invoices. subtotal, total and tax come back as decimal strings such as "181.50", while product prices are numbers.
• A contact spells its address differently from a customer. A contact has address1/address2; a customer has address/address_2. Both are modelled as the API sends them.
• Ticket status is the account’s own list. status takes any status name the account uses; the defaults are New, In Progress, Resolved, Invoiced, Waiting for Parts, Waiting on Customer, Scheduled and Customer Reply. priority takes one of Urgent, High, Medium or Low.
• Creating a product needs a description. RepairShopr rejects a product without one, so the schema requires it rather than letting the API return Name can't be blank.
• A rejection echoes what you sent. A 422 body carries every message at fault in message and the offending values in params, both exposed on the error.
• Deletes are permanent. customers.delete and tickets.delete have no undo and are marked destructive.
• Retries. RepairShopr documents no throughput window and no Retry-After, so a 429 is retried three times with exponential backoff. A 5xx is retried only for a call the plugin declared read-only.

• 18 typed API operations

​

Setup

npm install corsair @corsair-dev/repairshopr better-sqlite3
npm install --save-dev @types/better-sqlite3

yarn add corsair @corsair-dev/repairshopr better-sqlite3
yarn add --dev @types/better-sqlite3

pnpm install corsair @corsair-dev/repairshopr better-sqlite3
pnpm install --save-dev @types/better-sqlite3

bun add corsair @corsair-dev/repairshopr better-sqlite3
bun add --dev @types/better-sqlite3

import Database from 'better-sqlite3';
import { createCorsair } from 'corsair';
import { repairshopr } from '@corsair-dev/repairshopr';

export const corsair = createCorsair({
	plugins: [
		repairshopr(),
	],
	database: new Database('corsair.db'),
	kek: process.env.CORSAIR_KEK!,
	multiTenancy: true,
	hub: {
		projectApiKey: process.env.CORSAIR_API_KEY!,
		signingSecret: process.env.CORSAIR_SIGNING_SECRET!,
	},
});

repairshopr()

const { connectUrl } = await corsair.manage.connect.createLink({
	plugin: 'repairshopr',
	tenantId: 'acme',
});
// redirect the user's browser to connectUrl

​

Example API calls

const tenant = corsair.withTenant('acme');
await tenant.repairshopr.api.tickets.list({ customer_id: 1, status: 'New' });

const tenant = corsair.withTenant('acme');
await tenant.repairshopr.api.tickets.create({ customer_id: 1, subject: 'Laptop will not boot' });

​

What’s next