When a connection is not doing what you expect

Response codes

200

Accepted. The response body reports how many signals were recorded.

401

Missing, malformed or incorrect credential. For webhooks, the HMAC is computed over the raw body bytes — re-serialising the JSON before signing is the usual cause. For OTLP, check the bearer token and that you are calling your own connector's endpoint.

404

Unknown endpoint or a disconnected connector. Disconnecting deletes the credential, so a reconnect issues a new URL and secret.

409

The agent reference or resource attribute does not match any mapping on the connector. We answer 409 rather than guessing which agent you meant.

413

Body over 64KB, or more than 20 signals in one request. Split the delivery.

422

The payload parsed but failed validation — an unknown signal type, a summary over 400 characters, or a timestamp in the future.

429

Over 120 deliveries per connector per hour. Batch and retry with backoff.

Symptoms

The connector says connected but no signal appears in the feed

A connection test proves we can reach you; it does not create evidence. Signals appear only once an agent mapping exists and a delivery or poll carries data for that mapped reference.

A signal is listed but reads stale

Freshness is capped by the requirement's cure window — 30 days on most carrier conditions. A signal older than that reverts the requirement to attested. Send on a cadence shorter than the window rather than once at onboarding.

A requirement still reads attested although the signal is fresh

Only requirements whose evidence type matches the signal are upgraded. A drift_monitoring signal will not satisfy a change-control requirement. The report's evidence tier side-sheet names which signal each requirement is waiting on.

The heartbeat is answering but the connector is failing

A poll that answers and reports no monitoring is a positive finding, not silence: it means a control you believe you have is absent. It is recorded as a control gap against your monitoring and shown as failing on purpose.

The OTLP connector never leaves waiting for first signal

The RiskBorne OTLP receiver is not accepting traffic yet. Nothing sent today is stored. Use the webhook or heartbeat until the receiver goes live.

Still stuck

Read the webhook and heartbeat contracts or the OpenTelemetry guide, then report a problem from Settings in the app — the report carries the connector's recent delivery log so we can see what you saw.