API (Beta)

Platform health endpoints

Check whether OutboundSync is available with the public /health/live and /health/ready endpoints — JSON status, per-component checks, and 200/503 semantics.

When to use this guide: Poll these endpoints to programmatically confirm OutboundSync is available while you build and operate an integration. They are lightweight health checkpoints — a complement to, not a replacement for, the OutboundSync status page.

OutboundSync exposes two public health endpoints so you — and any uptime monitor you run — can check platform availability without an API key. They are unauthenticated (no cookies, no Bearer token) and set Cache-Control: no-store so every response is fresh.

Base URL

https://app.outboundsync.com

The health endpoints live at the root of the platform host, alongside the developer API.

GET /health/live

Try it in the console

Liveness — is the OutboundSync platform process up and serving requests? This endpoint always returns 200 when the process is reachable and does no downstream checks. Use it for basic up/down monitoring.

curl 'https://app.outboundsync.com/health/live' \
  -X GET

{
  "schema_version": 3,
  "status": "operational"
}

GET /health/ready

Try it in the console

Readiness — can the platform receive events and sync them right now? GET /health is an alias for the same response. Point uptime monitors at this endpoint.

curl 'https://app.outboundsync.com/health/ready' \
  -X GET

{
  "schema_version": 3,
  "status": "operational",
  "checks": {
    "sources": "operational",
    "destinations_activities": "operational",
    "destinations_forwarding": "operational",
    "destinations_blocklists": "operational",
    "destinations_reply_relays": "operational"
  }
}

Response fields

Field	Type	Description
`schema_version`	`number`	Version of this response contract. Currently `3`. New checks are added under `checks`; treat unknown keys as forward-compatible.
`status`	`string`	Overall rollup: `operational`, `partial_outage`, or `major_outage`.
`checks.sources`	`string`	Inbound event ingestion — `operational` or `outage`.
`checks.destinations_activities`	`string`	CRM activity and contact sync — `operational` or `outage`.
`checks.destinations_forwarding`	`string`	Event forwarding to your configured URLs — `operational` or `outage`.
`checks.destinations_blocklists`	`string`	Block-list sync back to your sequencer — `operational` or `outage`.
`checks.destinations_reply_relays`	`string`	Reply relays / Reply-CC to sales-rep inboxes — `operational` or `outage`.

The destinations_* checks are only present where the background worker is monitored (production and staging). In local development they are omitted and the response contains sources only.

What each check covers

sources — inbound event ingestion: sequencer webhooks and platform ingress. The developer API shares this path.
destinations_activities — syncing activities and contact updates into your CRM.
destinations_forwarding — forwarding received events to the customer URLs you configure.
destinations_blocklists — syncing CRM block lists back to your sequencer block lists.
destinations_reply_relays — Reply-CC / reply relays that transfer prospect replies to a sales-rep inbox.

Status and HTTP semantics

The overall status is derived from the individual checks:

`status`	Meaning	HTTP code
`operational`	No checks are in outage.	`200`
`partial_outage`	At least one check is in outage, but not all.	`200`
`major_outage`	Every check is in outage (a total outage).	`503`

Each check is binary: operational or outage.

A 503 is returned only for a total outage. If one component is degraded while another is still working — for example, event ingestion is down but forwarding is up — the status is partial_outage and the HTTP code stays 200. Uptime monitors should treat the JSON status (and the individual checks) as the source of truth, not just the HTTP code.

Only /health, /health/live, and /health/ready exist. Any other GET /health/* path returns a JSON 404 (Cannot GET /health/…), so a mistyped monitor URL fails loudly instead of looking healthy.

How this relates to the developer API

Platform health answers “is OutboundSync up?” — a different question from “is my integration working?”, which the authenticated API v1 answers. The full picture has four layers:

Layer	Endpoint	Auth	Answers
Platform liveness	`GET /health/live`	None	Is the platform process up?
Platform readiness	`GET /health/ready`	None	Can the platform receive and process events right now?
API connectivity	`GET /api/v1/me`	Bearer	Is my key valid, and which CRM connections can it access?
Account pipeline readiness	`GET /api/v1/account/status`	Bearer	Is my account configured and ready to sync?

Use the health endpoints for infrastructure-level monitoring and the API v1 endpoints for account-specific checks.

Status page

For a human-readable status overview and incident history, see the OutboundSync status page — also embedded as the System monitoring panel in the site footer. The health endpoints on this page are for programmatic checkpoints and complement that status page; they are not a replacement for it.