Talk to APPII
Integration platform

The integration platform
for every provider API.

APPII is an integration platform. It turns any provider API into a versioned blueprint you install per environment. Each connection carries its own credentials, and your apps call it by ID, as passthrough or through your own unified routes.

Start integrating See how it works
  • Blueprints
  • Installations
  • Connections
  • Unified mapping
> INSTALLATION · STAGING
“Install NASA Open APIs in Staging, call it with an API key, and serve a canonical /asteroids route.”
  • Blueprint published (v0.0.1)
  • Installed in Staging
  • Connection created with its own key
  • Unified route mapped
  • First call
STATUSConnected2 connectionspassthrough + unified
◉GET /planetary/apodReady
◉GET /neo/rest/v1/neo/browseReady
⌁GET /unified/asteroidsReady
◇GET /unified/picture-of-the-dayMapping…
▣BlueprintsVersioned, published once✓
⌘InstallationsOne per environment✓
◉ConnectionsOwn ID and credentials✓
⌁Unified routesYour canonical API✓
Why an integration platform

Integrations are a product of their own.

Every new provider costs the same work again: authentication, environments, credentials, response shapes, rate limits. APPII does that work once, in one place, for every integration you ship.

▣

Ship integrations your customers use

Offer integrations inside your product. Publish a blueprint once and install it for each customer or environment, with credentials kept per connection.

⌁

Put one API in front of many

Several providers can answer the same canonical route. Your app calls /unified/contacts and never learns which provider is behind it.

◫

Deliver client integrations faster

Describe a provider in a file, review it, publish it and install it. Teams repeat the same flow for every client instead of writing a new integration each time.

The model

Stop rewriting provider plumbing.

Every provider has its own paths, authentication and quirks. APPII separates what a provider is, where you run it, and who uses it, so each part is defined once and reused.

ϟOne blueprint.
Many environments.
Many connections.
▣

Blueprints

Describe a provider API once: folders, endpoints, example requests and the authentication it supports. Draft, publish, version and deprecate. A published version never changes underneath you.

Describe a provider →
⌘

Installations

Install a version into an environment such as Production or Staging. Set the provider address and choose which authentication methods connections may use.

Install a version →
◉

Connections

Create as many as you need, one per team or app. Each has its own ID, its own authentication method and its own encrypted credentials.

See how credentials are kept →
⌁

Unified routes

Map provider endpoints to your canonical API with a visual mapper. It is optional. Nothing needs a mapping to install or to call.

Map visually →
How it works

Describe it. Publish it.
Call it by ID.

The studio works like a request collection. Add endpoints, publish a version, install it, and hand your apps a connection ID.

ϟNothing secret in the blueprint.
Credentials live on the connection.
  1. 01

    Describe the provider

    Build it in the studio or import a YAML or JSON file.

  2. 02

    Publish a version

    Publishing freezes it. Changes go into the next version.

  3. 03

    Install per environment

    Provider address, allowed authentication, optional mapping profile.

  4. 04

    Create connections

    Name one per app. Add credentials to each connection.

  5. 05

    Call by connection ID

    Passthrough or unified. APPII adds the credentials for you.

  6. 06

    Operate and audit

    Rate limits, metrics and a trail of every credential change.

Passthrough or unified

Call the provider as it is, or through your API.

Both modes use the same connection ID. Pick per call.

  • Passthrough sends the request to the provider with its real paths, status codes and headers. Responses come back as the provider sent them.
  • Unified gives your apps stable canonical routes. APPII picks the provider endpoint and reshapes the response with the mapping you defined.
  • Credentials, rate limits and egress rules apply in both. Large and non-JSON responses stream through.
Request
curl -X GET "$APPII_HOST/passthrough/planetary/apod?date=2026-10-01" \
  -H "x-appii-connection-id: <connection-id>" \
  -H "x-appii-instance-id: <installation-id>"
Response · provider as sent200
{
  "date": "2026-10-01",
  "title": "NASA Science",
  "explanation": "What does it take to image hundreds of nebulas? …",
  "media_type": "image",
  "service_version": "v1"
}
Visual mapping

Map fields by dragging. See the result as you go.

Reshape any provider response into your own model without writing a line of code. Prefer code? The same mapping opens as JSONata.

  • Start from a pasted sample, a saved response model or a live call.
  • Drag provider fields onto canonical fields, or let auto-map match them by name.
  • Convert to text, number or true/false, set defaults, combine fields, or return a fixed value.
  • Rename query parameters on the way in for providers that name them differently.
  • The preview runs the same evaluator that runs in production.
Configuration files

Describe an integration in a file. Let AI write it.

Onboard a provider from one YAML or JSON file: folders, endpoints, authentication, sample responses and unified mappings. Credentials never go in the file.

  • Copy the prompt. It includes the schema and a worked example.
  • Paste the provider's docs or OpenAPI spec into your AI assistant.
  • Import the answer. Validation names the exact field that is wrong before anything is created.
  • Export any integration back to the same format to review, version or reuse it.
nasa-open-apis.appii.yaml · appii/v1
apiVersion: appii/v1
kind: Integration
metadata:
  name: NASA Open APIs
  category: Science
spec:
  authentication: api_key      # or a list: [api_key, bearer]
  publish: true
  folders:
    - name: Near Earth Objects
      endpoints:
        - name: Browse asteroids
          method: GET
          path: /neo/rest/v1/neo/browse
mappings:
  - name: NASA science
    routes:
      - method: GET
        path: /asteroids
        endpoint: GET /neo/rest/v1/neo/browse
        request:
          params: [{ from: limit, to: size }]
        response:
          records: near_earth_objects
          fields:
            id: id
            hazardous: is_potentially_hazardous_asteroid
Build less. Compose better.

One catalog for the whole organization.

Organizations are hierarchical. A child organization sees its own integrations and the published ones of its ancestors. Seeing a blueprint never grants edit rights, or access to a parent's installations, credentials or connections.

ϟ APPII owns

  • Blueprints, versions and lifecycle
  • Installations and connections
  • The encrypted credential vault
  • Mapping and the execution engine
  • Tenant isolation and audit

♙ Plugs into what you run

  • Your OpenID Connect provider for sign-in
  • PostgreSQL for each service's data
  • Kubernetes for deployment
  • Prometheus for metrics
  • Your providers, with your own accounts and keys

“Define the provider once. Reuse it in every environment and every app.”

Security by design

Credentials stay where they belong.

Provider secrets are the most sensitive data the platform holds. The design limits who can read them, for how long, and for which connection.

◉

Per-connection vault

Credentials are encrypted with AES-256-GCM, with a separate data key per tenant, bound to the connection. No API ever returns a secret.

⌁

Signed identity

The portal signs every request with an Ed25519 key. Services and the engine hold public keys only, so a compromised service cannot impersonate a tenant.

◫

Scoped service tokens

The engine reads credentials with a token that lasts under a minute and names one tenant, one installation and one connection.

↻

Key rotation

Every ciphertext carries a key ID. Add a key, run the re-encrypt job, retire the old one. Nobody re-enters a credential.

⇲

Egress guard

The engine connects only to public addresses on your allowlist, checked at connect time. Redirects are refused, so a provider address cannot reach your internal network.

▤

Least-privilege data

Each service has its own database role with data access to its own schema only. Migrations run as separate jobs under a different role.

Built for production

Run it like the rest of your platform.

Standard containers, health probes and metrics. Deploy with the Kubernetes manifests, point it at your database and your identity provider.

Your appsconnection ID + request
→
APPIIGateway · Catalog · Instances · Connections · Tenants
EngineMappingVaultAudit
→
Provider APIscredentials added for you
Prometheus metricsTrace ID on every log lineRate limits per installationAudit of credential changes and readsPod disruption budgets and probesDefault-deny network policy
Get started

What are you connecting?

Name the providers and what your apps need to do. We will tell you how it maps onto blueprints, installations and connections.

No technical specification required. Describe the outcome you need.