Self-hosted API gateway

API access.
Clearly controlled.

Ninox, Make or your script only get a token for approved actions. The real API keys for AI, shop, CRM or accounting stay on your server. Everything is set up in the admin interface.

Schleuse checks the approval between client and provider API CLIENTRequest PROVIDERTarget API SCHLEUSE Checks approval Keys on the server CONTROLLED API ACCESS
CLIENT → GATEWAY → PROVIDER Approval required
18 connector templatesTokens valid until revokedBody templates & parametersKeys AES-encryptedOpen source · GPL v3

Use cases

What you can do with it.

Wherever a low-code tool or script needs an API whose key shouldn’t end up with your customer.

NinoxButton Schleusechecks & adds Claudeor OpenAI TokenAPI key

AI right from Ninox

A button drafts payment reminders, replies or summaries. The AI key never appears in the Ninox script – Ninox only knows the Schleuse token.

POST /actions/claude-text
MakeScenario Schleusechecks & adds NinoxDatabase TokenAPI key

Make reads and writes Ninox

Make fetches records or creates new ones. The Ninox API key opens every database – it stays in Schleuse, and Make only gets the approved actions.

GET /actions/ninox-record?id=12
NinoxOrders Schleusechecks & adds WooCommerceShopify TokenAPI key

Shop data in the back office

Read orders and products from the shop and change the order status right from Ninox. Fixed GraphQL queries for Shopify.

PUT /actions/woo-status?id=815
NinoxCustomers Schleusechecks & adds HubSpotLexware Office TokenAPI key

CRM and accounting

Search and create contacts in HubSpot or Pipedrive, read open invoices from Lexware Office or sevDesk.

POST /actions/hubspot-search

Setup in the interface

Four steps. No terminal.

This is what the admin interface looks like. All examples use test data. Screenshots show the admin interface, which is currently in German.

Screenshot: choosing a template in the Schleuse admin

01 · Choose a template

Pick a provider, enter the customer and IDs, store the key once. Matching actions are already prepared.

Screenshot: testing an action in the Schleuse admin

02 · Test an action

One click calls the real target API. The preview instantly shows which data comes back.

Screenshot: creating a token in the Schleuse admin

03 · Create a token

Select the actions of one customer. Default: unlimited until revoked – no login every 15 minutes.

Screenshot: Ninox snippet in the Schleuse admin

04 · Paste into Ninox

A ready-made script for Ninox, settings for Make or a curl command – copy, fill in your values, done.

Connector templates

Common B2B systems. Ready to go.

Target address, authentication and typical actions are already filled in. You add your own APIs the same way. “Per provider docs” means: built from the official documentation, not yet tested with a real account.

Try it out

  • WordPress.org (test source)Public news API from WordPress.org. Ideal for a first test without an account of your own.tested

Database & low-code

  • NinoxRead, create and update records in Ninox Cloud or Ninox On-Premise.tested
  • AirtableRead and create records in an Airtable base.per provider docs
  • NotionQuery Notion databases and create entries.per provider docs

Automation

  • Make (webhook)Send data from Ninox or a script to a Make scenario. The webhook stays protected by an API key.per provider docs
  • n8n (webhook)Send data to an n8n workflow. Protected by header authentication.per provider docs

CRM & sales

  • HubSpot CRMRead, search and create contacts.per provider docs
  • PipedriveRead persons and deals, search and create persons (API v2).per provider docs

Accounting & invoices

  • Lexware Office (lexoffice)Read contacts, open invoices and vouchers.per provider docs
  • sevDeskRead contacts and invoices.per provider docs

Shop & website

  • WooCommerceRead orders and products, change the order status.per provider docs
  • ShopifyRead orders and products via fixed GraphQL queries.per provider docs
  • WordPress (your own site)Read posts on your own website and create drafts.per provider docs

Payments

  • StripeRead customers and balance, create customers.per provider docs

Communication

  • SlackSend messages to a fixed channel.per provider docs

Development

  • GitHubRead repository data and issues, create issues.per provider docs

AI

  • Claude (Anthropic)Generate text with Claude without the API key sitting in the client.per provider docs
  • OpenAIGenerate text with an OpenAI model without the API key sitting in the client.per provider docs

What an action can do

Exactly as much as needed.

Path placeholders

/orders/{id}

The client passes ?id=815. URL-safe values only, no switching paths.

Approved parameters

page, search

For paging and filters. The client cannot change fixed values like ?status=publish.

Body templates

{"properties": {"email": "{{email}}"}}

The structure stays in Schleuse, the client only supplies the values. Ideal for Ninox, GraphQL and AI.

Auth methods

Bearer · Basic · x-api-key

Key in a header, username and password, or public APIs. Plus fixed extra headers.

Clear answers

200 · 400 · 401 · 403

Clear error messages that name the missing value. Diagnostics show status, source and duration.

Built-in protection

AES-GCM · CSRF · Limits

Keys encrypted, no redirects, internal networks blocked, 60 calls per minute and token.

Interactive demo · sample data

What gets through?

Pick an action for the same token. The simulation shows how Schleuse reacts to an allowed or a blocked request.

Choose an action
Simulated response Ready
GET /actions/customer-list
No request sent yet.

The test runs with sample data in this browser.

  1. Client
  2. Schleuse
  3. Provider API

The principle

One action. One approval.

01 · Connect

Store the target

The admin interface stores the provider key encrypted and defines target, method, path and allowed inputs.

02 · Approve

Issue a token

A token gets exactly the actions of one customer – unlimited or time-limited, revocable at any time.

03 · Execute

Relay the call

Schleuse checks token, approval and inputs. The gateway inserts the provider key only when forwarding the request.

Questions

In short.

Do I need a Ninox API key?

Only if Make, n8n or a script should access Ninox. If Ninox itself calls an external API, Ninox only knows the Schleuse token; you enter the target API’s key in Schleuse.

How long is a token valid?

By default until it is revoked. You can also choose a duration in days; for fewer than 30 days Schleuse asks whether that is intended. Revoking takes effect immediately.

What can someone see who can read the Ninox script?

The Schleuse token – not the API key. The token only allows the approved actions of one customer, with fixed targets and checked inputs.

Do I have to configure anything on the server?

Not after installing with Docker Compose. You manage connections, actions, tests and tokens in the admin interface.

Is the admin interface available in English?

Not yet. The admin interface and the documentation are currently in German.

What doesn’t work yet?

Automatic OAuth renewal (Google, Microsoft 365), file uploads and downloads, streaming, and responses over 2 MiB or 30 seconds.

Self-hosted · version 0.3

On your server.

Start the gateway with Docker Compose on a Linux server. The installer checks for free ports first. After that, everything runs through the admin interface: templates, tests, tokens and diagnostics.

# In the unpacked project folder
./install-server.sh --plan --show-used
./install-server.sh --prepare
./install-server.sh --install