Import into Salesforce — CSV, Excel & PDF

• Overview
• From
• Into

Importing for your users — or for yourself?

Building a product that feeds Salesforce? An AppExchange or sync product, consultancy onboarding tooling, a product that writes into customers’ orgs — this page is your integration guide: your users bring files, clean records land in the org (and your backend sees every row first), and nobody leaves your app. Read on.

Just trying to get your own file into Salesforce? You have the file and the org; the file is the problem — renamed headers, merged columns, a PDF where a spreadsheet should be. See the wizard handle genuinely messy files in the playground (free, no signup). And a run-it-yourself importer is in the works: your own Salesforce credentials, runs on your machine, every row staged for review — and revertible after it lands. Join the waitlist.

Goal: your users bring the file they have — CSV, Excel, even a PDF or a scan — and clean records land in Salesforce without leaving your product, and without you writing a mapping/validation UI. The pattern is the same every time: embed → validate → deliver. Mildport handles the first two; your webhook handler owns the Salesforce API call.

1. Embed the importer

<mildport-import
  api-base-url="https://imports.your-infra.example"
  license-key="SIGNED_TENANT_KEY"
  catalog-key="salesforce"
></mildport-import>

2. Publish a catalog that mirrors Salesforce

The schema lives in a target catalog, not in host code. Create it in the catalog editor (/admin/catalogs on your engine, or embed <mildport-catalog-editor>), match Contacts and Accounts (and Leads if you write those), and publish. The widget loads that published catalog by catalog-key.

Keep keys aligned with Salesforce API names (LastName, Email, Phone, Name on Account). Mark fields your org’s page layouts treat as mandatory as required, and put picklist values on the field so the review step rejects unknowns before Bulk API does.

Users then upload anything — renamed headers, six languages, XLSX/ODS, even PDF tables — and Mildport’s deterministic matcher plus the review step produce typed, validated rows.

Need the schema computed per user at runtime, or versioned with your app? That’s the schema-as-code path — pass targets from host code instead of catalog-key.

3. Deliver from your webhook

Clean rows arrive on your signed apply webhook; your handler feeds Salesforce:

POST /services/data/v61.0/composite/sobjects for ≤200 records; Bulk API 2.0 ingest jobs for more

Salesforce-specific gotchas

• picklist and lookup fields fail on unknown values — validate against your org’s picklists in the review step.
• Bulk API is CSV-in, so a clean, typed export from the importer maps 1:1.
• duplicate rules can silently block inserts — surface the API’s duplicate errors back to the user.

Why not Salesforce’s own CSV import?

Data Loader and the Data Import Wizard live in Salesforce’s setup and on admins’ desktops — outside your product. If your product feeds a customer’s Salesforce org, the import UX has to live in YOUR app, with YOUR validation, and deliver through YOUR integration user.

---

Try the flow first: the playground (no signup), then the Quickstart and target catalogs. Prices are published — hosted and flat-annual self-host — at mildport.com/#pricing.