How should I expose multiple scientific-computing APIs for integration with Databricks and an ontology platform?

I’m building a portfolio of around 30 scientific-computing applications covering physics, quantum calculations, protein/biomolecular modeling, signal processing, and related mathematical tools.

The applications currently run on platforms such as Replit and Base44. I am considering exposing their computational capabilities through stable, documented APIs and integrating those services with Palantir Foundry.

The architecture I’m considering;

Scientific APIs → Integration/API Layer → Foundry → Ontology → Actions/Functions → Customer-facing applications

The solvers would remain independently deployed computational services. Foundry would provide the data, ontology, orchestration, permissions, and operational interface around them.

For example, a solver might expose:

POST /v1/quantum/solve

Input:
{
  "parameters": {...},
  "model": "...",
  "version": "1.2"
}

Output:
{
  "result": {...},
  "metadata": {...},
  "model_version": "1.2"
}

I would then want a Foundry workflow to invoke the appropriate computational service, persist the result and provenance, associate it with Ontology objects, and potentially expose the capability through an operational application.

For developers experienced with Foundry: what is the preferred pattern for this type of architecture?

Specifically:

  • Should external scientific calculators be represented primarily through Foundry Functions, Actions, or another integration mechanism?
  • What is the recommended way to invoke long-running external computations?
  • Should computational outputs become Ontology objects, properties, datasets, or some combination?
  • How should API authentication and secrets be handled?
  • How should external-service versions and scientific provenance be represented?
  • Are there established patterns for wrapping heterogeneous external APIs behind a consistent Foundry interface?
  • What limitations should I expect when an external computation is substantially heavier than a normal transactional API call?

The objective is to turn these ~30 independent scientific applications into reusable computational capabilities that can participate in Foundry workflows and ultimately support customer-facing applications.

I’m less interested in simply importing the applications and more interested in designing the integration correctly from the beginning.