Processing, deduplication, and privacy

Separate HTTP delivery from business completion and build reviewed regression fixtures.

Advanced Available on All plans Updated 8 October 2026

These pages describe ShellOrbit as it runs today. Breaking changes to the HTTP API are announced before they ship, and existing request and response shapes stay supported.

Deduplication and schema observations

Set an endpoint’s deduplication window from 0 to 168 hours. Zero disables it. Deduplication requires a verified provider event ID and is scoped to both the organization and endpoint. A duplicate reuses the accepted event ID without a new received-event charge or dispatch. Missing provider IDs are accepted normally. Your handler still needs business-level idempotency because outbound delivery is at least once.

Observe up to 50 dotted JSON field paths with string, number, boolean, object, array, or null types. Missing fields, changed types, and invalid JSON produce warnings; they do not reject delivery. Filter the event log by schema warnings.

Application processing receipts

A successful HTTP response is transport acknowledgment. Report business completion separately with a server-side write-scoped API key:

http
POST /v1/events/evt_example/processing
Authorization: Bearer shellorbit_your_server_key
Content-Type: application/json

{"state":"processed","reference":"order-123","detail":""}

Receipt states are processing, processed, and failed. Configure a processing deadline from receipt, up to 86400 seconds; zero disables monitoring. Monitored events start waiting and can become overdue. A later processed receipt wins over previous failure or overdue status; late processing/failure callbacks cannot undo completion. Event expiry prevents further receipts.

The scheduled monitor checks deadlines once per minute. Notices use the existing email and webhook alert preferences; webhook alerts require Pro or Business. Notice delivery is at least once with a stable idempotency key. A worker or notification failure can delay a notice. Processing status never changes the HTTP delivery outcome or received-event billing.

Privacy and reviewed fixtures

Set JSON paths and header names to mask in event inspection. customers.*.email masks that field in all array entries. Masking is case insensitive for headers. Preview the result using a reviewed sample. Invalid JSON is hidden when JSON masking is enabled, and response excerpts are hidden because they may echo original data.

Original bytes remain stored for verification and delivery. This is view masking, not deletion or outbound transformation. Imported fixtures receive the inspection copy, without original headers or signing secrets. Review and sanitize the edited payload, explicitly consent, and choose 1–90 days of independent fixture retention. Each organization can retain up to 100 active fixtures, with a 64 KB payload limit per fixture.

Export fixtures from the library and use the developer tools runner against an explicitly selected test target. Fixture export is a local file: deleting the server copy does not remove files already downloaded.