Skip to main content

Documentation Index

Fetch the complete documentation index at: https://nango.dev/docs/llms.txt

Use this file to discover all available pages before exploring further.

Many integrations need customer-specific behavior: custom field mappings, record filters, account IDs, feature flags, or provider-specific options. Large customers often have custom schemas in CRMs, ERPs, ticketing tools, and productivity apps, so one fixed integration path is rarely enough. Nango stores this configuration as metadata on each connection. Your functions read the metadata at runtime and adjust API requests, validation, transformations, or sync function schedules for that customer.

​
When this fits

Use per-customer configuration when:
  • Customers need to map external custom fields to your product model.
  • Different customers should sync different objects, folders, projects, or account scopes.
  • A function needs provider-specific account context after authorization.
  • You want one integration implementation with customer-specific behavior.
Avoid adding configuration before you need it. Start with a default path, then add typed metadata when repeated customer needs appear.

​
How Nango fits in

  1. Your app collects the customer’s choices during onboarding or settings.
  2. Your app stores those choices on the Nango connection as metadata.
  3. Nango functions read metadata while running for that connection.
  4. The same function code adapts requests and transformations for each customer.
Metadata is available to Action functions, sync functions, and event functions.

​
Common patterns

  • Fetch available custom fields with an action function, then store the customer’s mapping.
  • Store provider account IDs or workspace IDs discovered after authorization.
  • Use metadata to filter which records a sync function should fetch.
  • Start a sync function schedule only after required customer configuration exists.