The first door: the ERP's API, with your keys
Where the ERP has a public API, STRYKE uses it, and it signs in with the shop's own keys, never with a shared account of ours.
JobBOSS² (ECI) has one. In Settings, under Connections, a shop picks ECI's host from a fixed list (a typed address would send your keys wherever it pointed) and enters the client id, client secret, API key and company code from JobBOSS²'s API portal. Nothing is saved until JobBOSS² accepts them, names your company and lets STRYKE read its customers. A PO becomes an Order and the Job it creates. One honest limit: JobBOSS²'s public API has no customer create, so a PO from a customer not yet in JobBOSS² is held with a note to add the customer there first.
Odoo has one too. A shop enters its server address, the database name where one server holds several, an API key made for a user who can read and write sales and purchases, and the company name exactly as Odoo shows it. Self-hosted and Odoo.sh are open; Odoo Online needs a plan that allows the external API. A PO becomes a sales order with its partner; a customer Odoo does not have is created and marked as STRYKE's.
E2 Shop System is JobBOSS² under its old name (ECI's own words: "JobBOSS², formerly known as E2"), so a shop that has moved to JobBOSS² connects the same way. A shop still on the classic E2 install uses one of the two doors below.
The books: a sign-in at Intuit
QuickBooks Online is the one system that is not keys but a sign-in. An admin signs in at Intuit, picks the company, and STRYKE is connected to it. A vendor invoice becomes a Bill with the PDF attached; a shipment becomes an Invoice; a payment becomes a Receive Payment. A customer PO never goes to QuickBooks: it is an ERP document.
The second door: an import file
Where the ERP has an import, STRYKE writes to it: one CSV per entry, in the layout your import map expects, dropped where your import picks it up. This is the same door a shop's EDI translator used, if it had one. Its limit is that STRYKE cannot ask the ERP anything through it, so the duplicate check (has this PO already been entered?) waits for a person's one click before the file is written.
The third door: keystrokes
Where the ERP has neither, STRYKE's desktop runner, installed on one shop PC that is signed into the ERP, keys the entry into the ERP's own screens the way a person would. The entry is pending until the runner finishes and reads the result back. The same limit on the duplicate check applies, for the same reason.
"Tell us your ERP"
Epicor Kinetic, Global Shop Solutions and ProShop run many of the shops we talk to, and none of the three has a public API specification we hold. For these the Connections page has a "Tell us your ERP" door: you point STRYKE at your ERP's API documentation (a link, a PDF or pasted text; Kinetic serves its own REST help per instance) and give it the API address and the keys the documentation names. STRYKE builds the connection from the documentation and your keys and tests it, reads only, before anything is written. If your installation has no API at all, the import file or the runner is the answer, and the plan says which.
NetSuite is in pilot: STRYKE has a drafted connection from Oracle's SuiteTalk REST documentation (record/v1, OAuth 2.0 client credentials) that is not yet on the Connections page. A NetSuite shop starts from "Tell us your ERP" and the pilot settles it. Every system STRYKE enters into has its own page.
Which door, and what to have ready
The five-question plan asks "What runs your floor?" first, and the answer picks the door. For JobBOSS²: the host, client id, client secret, API key and company code. For Odoo: the server, the database, an API key and the company name. For QuickBooks Online: an admin who can sign in at Intuit. For an import file: your import map. For the runner: one shop PC. For the rest: your ERP's API documentation, or the admin who knows where it is. Whichever door it is, nothing is installed in the ERP, and the product page shows what the entry looks like once it is there.