Skip to main content
The OSA Partner API connects an adjusting firm’s claims system to OSA. Your system sends a claim to a named adjuster; the adjuster accepts or rejects it in the OSA app on their phone or tablet; your system sees the outcome by polling. The API covers flood claims on properties in the United States and its territories.

​
How it works

1

Invite your adjusters

Invite each adjuster to your firm by their OSAID, the account id on their profile in the OSA app (the field labelled OSA ID, which has a copy button). They accept the invitation in the app. Until they do, nothing about your claims reaches them. See Inviting adjusters.
2

Send a claim

POST /v1/claims with your own claim id (external_id), the claim details, and the adjuster’s OSAID. OSA returns its claim id and assignment.status: pending_acceptance. The adjuster is sent a push notification. Send the carrier’s details in full, and any of the optional claim details you have.
3

The adjuster responds

The adjuster accepts or rejects the claim in the app, optionally giving a reason for a rejection.
4

Poll for the outcome

GET /v1/claims?updated_since=… every few minutes. Accepted claims are with the adjuster. Rejected claims can be offered to someone else with POST /v1/claims/{id}/assignment.

​
Base URL

All endpoints are under /v1. Live and test keys use the same host; the key decides which data you reach.

​
Conventions

  • JSON everywhere. Requests and responses are application/json. Errors are RFC 9457 problem details (application/problem+json).
  • snake_case fields and lowercase enum values such as flood and pending_acceptance. US state and territory codes are the standard two-letter USPS codes (FL, PR), and flood zones are written as FEMA writes them (AE).
  • Enums are open. New values can appear in responses at any time. Treat values you don’t recognise as “other” rather than failing.
  • Strict requests. An unknown or misspelled body field or query parameter is rejected with 422 validation_failed, so a typo never silently drops data.
  • Your id comes back. Every claim response includes your external_id, so you can match claims without storing OSA’s id.
  • Every response has a request id. The X-Request-Id response header identifies the call. Log it, and quote it if you contact OSA about a request, including one that succeeded.
  • Dates. Timestamps are RFC 3339 in UTC (2026-09-28T14:32:11Z). Calendar dates such as the date of loss are YYYY-MM-DD and are never converted between time zones.

​
Versioning

/v1 changes only additively: new endpoints, new optional request fields, new response fields and new enum values. Anything that would break an existing integration goes to a new version, announced well in advance in the changelog.

​
Get access

API access is set up with OSA directly. Once your agreement is in place, OSA creates your firm’s test accounts, sends your firm their sign-ins, and sends you a test key. Start with the quickstart.

​
Support

Email info@osaconnection.com for keys, limits, questions and problems. When you ask about a particular request, include its X-Request-Id.