Inspection Support Network

Build against ISN

Every ISN customer runs their own tenant, at their own address. That is why there are two APIs rather than one.

Four things to know first

Service domain: The customer's ISN domain, with no path — inspectionsupport.com, or a white-label domain like 4isn.com.
Company key: A unique lowercase slug identifying one customer. Every customer knows theirs; it is visible in their ISN URL.
API endpoint: Service domain, then company key, then rest — so https://4isn.com/yourcompany/rest. Each tenant is sandboxed at its own address.
Access keys: An access key and secret access key, generated by the user under Settings → My Access Keys. Prefer these over a username and password: a user can revoke them without changing their password.

Why there are two APIs

Because a tenant's address is not predictable, something has to tell you where a customer lives before you can call them. That is the only job the second API has — and if you already know the address, you never need it.

If you know the company key

Go straight to the ISN API

You are a customer integrating with your own ISN, or a vendor whose user has given you both their domain and their company key. Build the URL yourself and start calling. Orders, clients, agents, scheduling, fees, files.

ISN API reference → If you only have a company key

Ask the Admin API first

You support many ISN customers and only ever learn a company key — users usually know theirs but not their domain. One call resolves it to an address, then you continue against the ISN API as above.

Admin API reference →

The Admin API needs an integration username and password issued by ISN operations — separate from a customer's access keys, and issued to you rather than to them. Ask us for a pair before you build against it.

Guides

The reference lists every field of every operation. A guide fixes the order of calls for one job and says which fields matter.

If you book inspections from your own system

How to schedule an order

Find the client, find an inspector's open time, create the order as a draft, read it back, then schedule it. Eight calls, two of them write, and the three things the API will not check for you.

Schedule an order →

Or connect an AI assistant

Not every integration is code. ISN runs an MCP server, so Claude, ChatGPT and other assistants can look up orders, check availability and book inspections as a signed-in user, with no API keys to manage.

If you use Claude or ChatGPT

Connect it to your ISN

One URL, sign in with your ISN account, approve. Read tools answer questions about clients, agents, orders and revenue without a prompt; the nine write tools always ask first. The same page is written for connector-directory reviewers.

MCP server →

Or let ISN tell you

Instead of polling, register a URL and ISN POSTs a JSON payload to it the moment something happens — an order created, scheduled, paid, completed, rescheduled.

If you want to react to events, not poll for them

Register a webhook

One page in ISN Settings, one URL, and a list of order-lifecycle events to subscribe to. Every payload carries an event_id for dedup.

Webhooks →

Footprints

A footprint is a small pointer to an inspection that is coming up for the authenticated user. Two upcoming inspections, two footprints. They are the usual way an integration discovers new work without polling the whole order list.

Footprints must be deleted once you have read them. They stay in the queue until you delete them, or until the customer's retention setting purges them — whichever comes first. An integration that reads and never deletes will keep seeing the same work.

Worked example — you know the company key

Build the endpoint from the domain and company key.
```
https://4isn.com/yourcompany/rest
```

Ask for upcoming work, authenticating with the user's access keys.

curl -u "$ACCESS_KEY:$SECRET_ACCESS_KEY" \
  https://4isn.com/yourcompany/rest/orders/footprints

Each footprint carries an id. Follow it for the detail you need.
```
GET /order/{id}
GET /client/{id}
GET /agent/{id}
```
Delete the footprint once you have what you came for.

Worked example — you don't know the company key

Ask the user for their company key. They will know it; they often will not know their domain.

Resolve it with the Admin API, using your integration credentials.

curl -u "$INTEGRATION_USER:$INTEGRATION_PASS" \
  "https://isnadmin.com/rest/isn/url?companykey=yourcompany"

Read the url from the response. Check status rather than the HTTP code — an unknown company key still returns 200.
Continue exactly as above, against the address you were given. Cache it: a customer's address rarely changes.