Microsoft Sentinel
In obserae: use the Microsoft Sentinel output for alerts. The custom connector below is only for the inbound half — a Logic App asking obserae questions.
Two directions, two mechanisms, and they are independent: you can do either without the other.
Alerts in — the native output
Create a Microsoft Sentinel output. It writes into a custom Obserae_CL
table through the Logs Ingestion API, authenticating with an Entra ID
application. The fields you need — Data Collection Endpoint, the DCR’s
immutable id, tenant, application id and client secret — are described in
Outputs.
Sentinel also ingests OCSF natively. Set the output’s event schema to
ocsf and it sends a Detection Finding (class 2004) instead of obserae’s own
document — useful if you already normalise on OCSF across sources. See
Send it in your SIEM’s own language.
If you would rather have alerts arrive as incidents than as a table, point a Webhook output at an HTTP-triggered Logic App instead and build the incident yourself. Both are legitimate; the table is less work and the incident is more actionable.
Context out — a custom connector
This is the half the native output does not cover: a Logic App calling obserae to enrich what it received.
- Data connectors → Custom connectors → Import an OpenAPI file.
- Upload
openapi-soar.yaml. Take it from your own instance —GET /api/openapi-soar.yaml— so it matches the operations that instance serves. The server block is templated, so set the host to your instance. - Security: API Key, parameter name
Authorization, locationHeader, valueBearer obs_…. Logic Apps has no first-class Bearer type; the API-key form sends exactly the same header. - The fourteen operations appear as actions with typed outputs, so the
designer offers you
asn,countryandpolicy_coveredfrom the dynamic content picker.
If those fields do not appear in the picker, the import lost the response schemas. That is a defect worth reporting rather than a step to work around — the whole point of the typed profile is that they appear.