# AIP Community Registry: what people have actually built on the Palantir platform

> The AIP Community Registry is a catalogue of 28 community-contributed applications, SDKs and tutorials built on Palantir's AIP platform, from a Gmail connector to a whale sighting monitor. It is a list rather than a library, and its value is that each entry names a contributor and a working approach to a specific problem.

**palantir/aip-community-registry** — Collection of community-built applications and projects leveraging Palantir's AIP Platform.

- Repository: https://github.com/palantir/aip-community-registry
- Stars: 555 · Forks: 100
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/palantir-aip-community-registry

## A catalogue, with a contributor against every line

The AIP Community Registry is a list of awesome SDKs, frameworks, and workflows, built on Palantir AIP and contributed by the developer community.

The format is a table with four columns: a number, a demo, a description and a contributor. That last column is what makes this more than a link dump. Every entry names a person, and the descriptions are specific enough to tell you what approach was taken rather than what the platform offers in general.

Palantir AIP is described as a modular and interoperable developer platform that enables the rapid deployment of AI integrated operations, and the registry sits underneath that as a gallery of what people have done with it. There is also a prompt for newcomers to sign up for a free AIP Developer Account, which tells you the intended audience is developers evaluating the platform rather than users of a finished product.

The project is Apache-2.0 licensed, the primary language recorded for the repository is TypeScript, the default branch is develop, and the last push was on 2026-09-11. The repository publishes no GitHub releases and has no homepage, which is consistent with a collection of separate projects rather than a distributed artefact. The repository root also carries a .palantir/ directory, a Template/ directory, a _static/ directory with the banner image, and the two documents that make the whole thing usable: CONTRIBUTING.md and INSTALLATION.md, with PACKAGING.md alongside them.

## The entries cover connectors, tutorials and full applications

The 28 entries are not variations on one theme, and the spread is the interesting part.

There is a set of connectors to other systems. The Personal Gmail and Calendar Connector is an SDK enabling a bi-directional interface between Gmail, Google Calendar and the Palantir Foundry stack, and it includes cleaning logic, an Ontology layer and an OAuth set-up guide. The Small Business Connector connects with other like-minded people with suggestions driven with AIP by leveraging the semantics around your business. The Gmail Compute Module for Foundry is a compute module that sends emails via Gmail using a domain wide delegated service account.

There are tutorials that teach a specific platform mechanism. The OSDK 'Hello World' Project takes data from your Ontology and brings it into a local Jupyter Lab notebook through the OSDK. The Compute Module 'Hello World' Project does the same for an organisation's codebase. The OSDK Widget in Foundry tutorial is about creating a custom widget in Workshop for third party libraries. The Python Functions for parsing PDF Files with Tesseract OCR entry converts PDF pages into images and extracts text using OCR.

And then there are full applications, which is where the list gets interesting. Tailbook is an Ontology SDK to monitor global whale sightings and migrating patterns. MetroCycle is a software platform designed to manage key operations for a bike hire start-up. The WLED Controller and Agent Effect Scheduler creates an automated, context-aware lighting system that responds to holidays. The Geocoding with Nominatim entry is described as a production ready package to geocode addresses in bulk and realtime.

## The hackathon entries show what a team builds in a weekend

Two entries come from a hackathon, and they are worth reading as a pair because they describe the same scenario implemented two ways.

The ASWF 2024 Hackathon HADR Aid entry is a rapid response scenario for a fictional typhoon impacting Hawaii using a live streaming pipeline, the Ontology SDK, and a react frontend application. The ASWF 2024 Hackathon SARR APP entry is a rapid response scenario for the same fictional typhoon, also using the Ontology SDK and a react frontend.

Two teams, the same brief, different contributors, and both credited by name. That is a useful signal about the registry, because it means the entries are not a curated set with one house style. They are what a developer with a weekend produced, which for most readers is a more honest benchmark than a reference implementation would be.

The scenario is also a good illustration of the platform vocabulary the entries use. The Ontology SDK is the main way application code reads and writes platform data, a compute module is how you run server-side code, and a react frontend is the standard way to surface it to users. Once you have seen those three appear in two unrelated entries, the rest of the table reads much faster.

The other entries use the same vocabulary in different proportions. The Platform Governance App with Platform SDK uses the Platform SDK to run transformations in code repositories that pull Foundry metadata, meaning users, groups and resources, into datasets. The Push-Based Events entry provides a mechanism for Foundry to listen to events produced by another system, Jira in that example. The DevOps for AI Products entry explores the ticketing workflow demoed at DevCon 2 and develops workflows using marketplace release management.

## Installing an entry means uploading a zip, and the docs are in the repository

The Getting Started section splits the audience in two, which is the right structure for a registry.

For users there are three steps. Browse the table above to find relevant examples. Follow the Installation Guide, INSTALLATION.md, to deploy the package to your Foundry environment. Then refer to instructions found in the project folder for any additional installation or configuration steps.

The Installation - Quick Reference at the end of the README makes the deployment concrete. You download the package .zip file, and then upload the zip file on your Dev Tier Enrollment, with a note that enterprise users may need to work with a different path, and the sentence is cut off in the version of the README available here.

So the mechanism is a browser upload of a packaged application into a Foundry environment, not a package manager install. That is the right shape for a platform where the artefacts are applications deployed into a workspace rather than libraries imported into a project, and it explains why every entry in the table is a self-contained project folder with its own instructions.

The repository layout matches that. Each entry has its own directory, named after the demo, and alongside them sit the shared documents, INSTALLATION.md, PACKAGING.md and CONTRIBUTING.md, plus a Template/ directory that presumably holds the skeleton a new entry starts from.

For contributors the instruction is short. If you have built something impactful on AIP, please follow the instructions in CONTRIBUTING.md to get it added here. The existence of a Template directory and a PACKAGING.md document is what makes that request practical rather than aspirational, since the two together define what a well-formed entry looks like.

## What the registry is good for, and what it is not

It is worth being clear about the shape of this repository, because a name like registry suggests a package index and this is not that.

There is no installable package, no dependency to add and no version to pin. Each of the 28 entries is an independent project with its own dependencies, its own configuration and its own deployment steps, and the registry is the index that tells you what exists and who built it.

What that buys you is something a documentation site cannot. A documentation site shows you the platform's capabilities. A registry shows you how a specific person solved a specific problem, with a name attached, and the names are a decent proxy for whether the approach will survive contact with your data.

The list is also honest about the shape of the applications. Several entries are mobile app SDKs, Meal Planning, Renovation Planner, Peak Explorer, Fashion Assistant and Personal Finances among them, and they describe themselves that way. Several are Computer Vision enabled, Meal Planning and Fashion Assistant again. That tells you something about the platform's current centre of gravity in community projects, which is a different kind of information from the feature list.

The remaining caveat is coverage. Twenty-eight entries is a snapshot, the entries range from a one-line OAuth guide to a full application, and the descriptions are short enough that a project may be more or less finished than its table row suggests. Reading the project folder is the only way to know, which the documentation tells you to do.

## Conclusion

Use the AIP Community Registry as a catalogue of working approaches if you are building on Palantir's AIP platform, because the entries are real implementations rather than snippets and each names its contributor. Do not treat it as a dependency source, since it is a list of separate projects with their own installation steps and the registry itself installs nothing. Before you pick an entry, read the INSTALLATION.md and the per-project instructions rather than the table description, and note that the repository has no releases and no home page, so there is nothing to install from the registry itself.

## FAQ

### What is the AIP Community Registry?

It is a list of awesome SDKs, frameworks, and workflows built on Palantir AIP and contributed by the developer community, presented as a table with 28 entries and a named contributor for each one. The repository itself is Apache-2.0 licensed and publishes no releases.

### How do I deploy one of the registry projects?

Find a relevant example in the table, follow the Installation Guide in INSTALLATION.md to deploy the package to your Foundry environment, then follow any extra instructions in the project folder. The quick reference is to download the package .zip file and upload it on your Dev Tier Enrollment, with enterprise users possibly needing a different path.

### What kinds of projects are in the AIP Community Registry?

They range from connectors to other systems, such as a Personal Gmail and Calendar Connector, a Gmail compute module and a Small Business Connector, through tutorials that teach one mechanism, such as the OSDK and Compute Module hello world projects, to full applications like Tailbook for whale sightings, MetroCycle for a bike hire start-up and a WLED lighting scheduler.

### How do I add my own project to the AIP Community Registry?

The README asks you to follow the instructions in CONTRIBUTING.md if you have built something impactful on AIP. The repository also carries a Template directory and a PACKAGING.md document alongside INSTALLATION.md.

## Sources

- [Issues](https://github.com/palantir/aip-community-registry/issues)
- [License: Apache-2.0](https://github.com/palantir/aip-community-registry/blob/develop/LICENSE)
- [palantir/aip-community-registry on GitHub](https://github.com/palantir/aip-community-registry)
- [README](https://github.com/palantir/aip-community-registry/blob/develop/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/palantir-aip-community-registry
