JobBOSS2 API: Documentation, Keys and Integration Options

Choose and set up an integration

1. 1Write down the integration goal: push orders in, pull job status out, feed a dashboard, or let an assistant answer questions. The goal decides the method.
2. 2Ask ECI or your reseller in writing whether your edition includes an API, what it covers (read, write, which objects), and how keys or credentials are issued and rotated.
3. 3For read-only reporting, create a dedicated SQL Server login with SELECT permission on the needed tables or views, and nothing else.
4. 4For writes, prefer the vendor API or supported import routes over inserting directly into tables, since the application enforces business rules the database does not.
5. 5Build against a test copy of the system, with test data, and log every request.
6. 6Store credentials in a secrets manager, never in scripts or spreadsheets, and give each integration its own account so you can revoke it.
7. 7Monitor failures and rate limits, and agree who gets alerted when an integration stops.

Safe read-only SQL access

CREATE LOGIN integ_readonly WITH PASSWORD = '***';
USE [YourJobBossDb];
CREATE USER integ_readonly FOR LOGIN integ_readonly;
GRANT SELECT ON SCHEMA::dbo TO integ_readonly;

-- Or narrower: grant on a view only
GRANT SELECT ON dbo.vw_open_jobs TO integ_readonly;

Common pitfalls

• !Assuming a public API with self-service keys exists. Confirm with ECI.
• !Using the application database login for integrations.
• !Writing straight into tables, which bypasses application rules.
• !Building queries on internal tables that change between versions, with no view layer.
• !Hard-coding credentials in scripts.
• !Testing against live data.