Palantir Event and Subscription Integration

Overview

Start from the event producer and delivery guarantee: real-time Ontology object updates use OSDK or Object Set Watcher WebSocket subscriptions, while monitoring notifications and outbound integrations use their documented webhook surfaces. Never invent a general ontology.object.created registration API.

Prerequisites

• Identify the producer, consumer, object set or monitoring view, supported delivery surface, data sensitivity, latency objective, and recovery behavior.
• Confirm the generated OSDK version or direct WebSocket contract, or the configured Data Connection webhook required by monitoring.
• Read references/official-docs.md and verify target-enrollment feature access.
• Prepare a non-production object set or monitoring view and an idempotent consumer.

Current Contract

• TypeScript OSDK subscriptions require a compatible generated OSDK/client and receive object-set updates through .subscribe.
• Direct Object Set Watcher subscriptions use a documented WebSocket endpoint and authenticate with a bearer token encoded in the WebSocket subprotocol format.
• Subscriptions can report an out-of-date state that requires reloading the full object set.
• Monitoring views can route notifications through webhooks configured in Data Connection; that is distinct from Ontology object subscriptions.

Authentication

Use the generated OSDK token provider or the documented WebSocket bearer subprotocol. For outbound webhooks, use the authentication configured by the supported Data Connection webhook. Never invent or assume a signature header; record the actual configured authentication and secret owner.

Instructions

1. Classify the event need as Ontology object-set change, monitoring notification, or another documented Foundry integration.

2. Choose TypeScript OSDK subscription, direct WebSocket, or monitoring/Data Connection webhook and document why it matches.

3. Define bounded object filters or monitoring criteria, returned properties/message content, authentication, reconnect/backoff, and cancellation.

4. Implement idempotency and durable reconciliation; on onOutOfDate, disconnection, or delivery gap, reload authoritative state.

5. Test create/update/delete or alert cases, duplicate delivery, reconnect, stale state, denied access, secret rotation, and consumer recovery.

Tool Discipline

• Use Glob to locate candidate repositories, manifests, configurations, and evidence without widening scope.
• Use Grep to find relevant identifiers, declarations, permissions, errors, and stale claims.
• Use Read to inspect the smallest required files and authoritative evidence.
• Use Write only for a new approved local draft, test, manifest, or evidence artifact.
• Use Edit only for a bounded approved change whose rollback is known.
• Do not use file tools as a substitute for authenticated Foundry operations or owner approval.

Approval Boundaries

Ontology and data owners approve subscribed objects/properties; security owners approve authentication and outbound destinations; monitoring owners approve notification routing. A subscription does not authorize writeback.

Output

An event contract with producer, supported surface, filter, payload fields, auth, consumer, delivery/reconnect behavior, idempotency key, reconciliation, tests, observability, and disable procedure.

Error Handling

Examples

Example 1

Subscribe to an approved Equipment object set with TypeScript OSDK, select only required properties, handle updates and deletion, and reload on onOutOfDate.

Example 2

Route a monitoring-view severity to a preconfigured Data Connection webhook, validate the Message input mapping, destination controls, duplicate handling, and disable path.

Validation

• The chosen surface is explicitly documented for the producer.
• Filters and returned data are least privilege.
• Authentication and secret rotation match the selected surface.
• Duplicates, disconnects, out-of-date state, and reconciliation are tested.
• Consumer failure cannot silently lose authoritative state.

Resources

• Official documentation and contract notes
• Re-check the dated contract before any live operation.
• Treat unresolved or changed vendor behavior as a stop condition.