Platform embedding: one integration, many customers

You are a platform — a CRM, an ERP, a vertical SaaS — and you embed Mildport once. But the people importing files are your customers, each with their own data, their own column vocabulary, their own compliance posture, and their own idea of how much AI help they want. This page explains the two ways to serve them, what each one guarantees, and how to choose.

The rule of thumb

Ask one question: do your customers need to be isolated from each other, or only told apart?

• Told apart → use one license and pass your own customer reference on every import. Cheap, zero provisioning.
• Isolated → give each customer their own tenant (own license key). Each gets a private vocabulary, private settings, private destinations, and private limits.

Everything else on this page is detail on those two options.

Option 1 — one license, your customer reference

Your integration keeps a single license key. On every import you pass your own identifier for the end customer — an opaque string you choose, called externalId in the REST API:

• It is stored with the import and echoed back on reads and in apply deliveries, so your backend always knows which of your customers a record belongs to.
• The widget can show each customer a different subset of your field catalog — either by passing the fields inline per embed, or by publishing one catalog and applying a stored per-project subset (the catalog-project attribute; see target catalogs).
• Widget behavior (accepted formats, PDF mode, sample data, review options) is per-embed configuration, so it can differ per customer already — see configure the widget.

What this option does not do: it is a label, not a wall. All customers share one learned mapping vocabulary, one set of AI settings, one webhook destination list, and one usage pool with one set of limits. Filtering reads by your reference is your responsibility. That is the industry-standard “metadata echo” pattern — fine for separating inboxes, not for separating customers with privacy or budget boundaries between them.

When is the label enough?

When your customers are departments of the same organization, or when the imported data all lands in one backend you own anyway. The moment two of your customers are distinct companies whose vocabulary, settings, or spend must not mix, move them to Option 2.

Option 2 — a tenant per customer

From your customer panel you can create additional tenants, each with its own license key, and dedicate one to each of your customers. Every such tenant is a full, hard-walled Mildport tenant:

• Private learned vocabulary. When one customer confirms that Zahlungsziel means Payment terms, that knowledge belongs to them alone — it never surfaces in another customer’s import. (How learning works: how matching decides.)
• Private settings and features. AI assistance can be on for one customer and off for another — including for compliance reasons — because features travel inside each customer’s own signed license.
• Private destinations. Each tenant registers its own apply webhooks, so each customer’s rows can be delivered to a different endpoint (webhooks).
• Private limits and usage. Row limits, rate limits and AI budgets apply per tenant, and your panel shows usage and activity per customer — who imported how much, who consumed the AI budget — with no reconstruction work on your side.

The keys are offline-verifiable signed tokens; nothing about this setup phones home, and it works the same in the cloud and self-hosted (self-hosting).

Selling AI selectively

Because features live in each customer’s license, a platform can resell AI assistance as its own premium tier: enable it in the licenses of customers who pay for it, leave it off elsewhere. No configuration flags to maintain in your own code.

Choosing at a glance

Your customer needs…	One license + reference	Tenant per customer
Separate inboxes / “whose record is this?”	✅	✅
A smaller view of a big field catalog	✅	✅
Different widget behavior per customer	✅	✅
AI on for some, off for others	—	✅
Private mapping vocabulary	—	✅
Own delivery endpoint	—	✅
Own limits, own usage line, own budget	—	✅

Mixing is normal: many platforms start with one license while integrating, then promote their larger customers to dedicated tenants as they onboard.

Operational notes

• Creating a customer tenant is a panel action today; if you provision customers programmatically and want to create tenants from your own onboarding flow, talk to us — this is an active area of the product.
• Keys can be rotated per customer without affecting anyone else.
• Usage in your panel is per tenant and per month; apply deliveries carry the tenant identity, so your rebilling can be driven from either.

Next: install the widget or read how it works for the delivery picture.