Ellipse Gradient for Header

Nasuni Integration Guide

Integrate Nasuni file data and management resources with enterprise systems through REST APIs, configured file-access protocols, scheduled workflows, and controlled data exchanges.

Nasuni integration options at a glance

Nasuni integrations primarily use management and administration REST APIs associated with the Nasuni Management Console and appliances, together with configured SMB, NFS, or S3-compatible access for file-oriented workflows. API authentication, resource availability, permissions, and endpoint versions must be confirmed for the deployment. General webhook coverage, GraphQL, SOAP, and standardized bulk APIs were not confirmed, so scheduled polling, manifests, checkpoints, and controlled file drops are often more appropriate for change detection. Martini can consume Nasuni APIs, process JSON and accessible files, apply validation and business rules, transform metadata, write to downstream systems, and expose normalized REST APIs for other applications.

Integration pointSupported by Nasuni?Common use casesHow Martini supports it
REST APIsYesNasuni Management Console and appliance APIs can expose administrative and operational resources such as Edge Appliances, Volumes, configuration, and status. API version, enabled resources, and permissions must be confirmed.Martini can consume the applicable REST endpoints, authenticate with environment-managed credentials, parse JSON responses, apply validation, and write normalized data to downstream systems.
File and protocol-based accessLimitedConfigured SMB shares, NFS exports, S3-compatible access, or shared-volume file exchanges can support file manifests, metadata processing, and controlled data movement.Martini can orchestrate file-oriented workflows where the deployment and network topology provide an accessible supported interface, with handling for locks, partial files, permissions, and completion markers.
Webhooks and outbound callbacksNot confirmedGeneral webhook coverage for file, volume, snapshot, or appliance events was not established. Event support should be verified for the specific Nasuni environment.Martini can receive webhook-style notifications when a customer-confirmed Nasuni callback exists; otherwise it can use scheduled polling, manifests, or controlled file drops.
Bulk and asynchronous APIsNot confirmedNasuni manages large-scale file data, but a generally available bulk or asynchronous management API was not confirmed.Martini can process large inventories incrementally using pagination where available, bounded concurrency, checkpoints, and retry-safe workflow execution.
AuthenticationLimitedManagement access uses NMC users and configured authentication; directory services can support access management, while file protocols and object access use deployment-specific permissions.Martini stores API and file-access credentials in environment secrets and keeps management-plane credentials separate from file-access credentials.
GraphQL APIsNot confirmedNo official Nasuni GraphQL API documentation was identified in the research.Martini should use the confirmed REST or file-oriented mechanisms rather than assume GraphQL availability.
SOAP APIsNot confirmedNo official Nasuni SOAP interface was confirmed.Martini can consume SOAP services generally, but a Nasuni SOAP integration should not be designed without customer documentation confirming the endpoint.
Database accessNoDirect access to internal Nasuni databases is not a documented standard integration approach.Martini should use supported APIs, file protocols, or configured object-access interfaces instead of connecting to internal Nasuni data stores.

How Nasuni exposes data and business events

Nasuni REST APIs

Nasuni provides management and administration APIs associated with the Nasuni Management Console and appliances. These APIs can expose administrative resources, configuration, operational information, Edge Appliances, Volumes, Shares, and Snapshots, subject to API version and permissions.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with environment-managed credentials, calls the applicable Nasuni endpoint, handles pagination or continuation behavior where available, validates the response, maps JSON into a canonical model, and writes the result to downstream systems or a database.

Implementation sequence

Authenticate with the confirmed Nasuni API scheme
Call the applicable NMC or appliance endpoint
Retrieve pages or incremental results where supported
Validate required identifiers and status fields
Map the response to the target data model
Upsert the result using a stable source key and checkpoint progress

Nasuni file and protocol access

Nasuni supports file-oriented integration through configured SMB shares, NFS exports, S3-compatible access, and shared-volume exchanges. Availability depends on deployment, permissions, network topology, and the selected interface.

Martini implementation pattern

Martini implementation pattern: a workflow processes a producer-controlled manifest or completion marker, reads accessible files or metadata, applies file consistency rules, transforms content, and sends the result to an API, database, or other supported enterprise endpoint.

Implementation sequence

Detect a confirmed manifest, completion marker, or scheduled processing window
Verify that the file is complete and not locked
Read the manifest or accessible source file
Validate paths, metadata, and required fields
Transform content and metadata for the target system
Store a durable checkpoint and route failures for retry or review

Scheduled Nasuni change detection

General Nasuni webhook coverage was not confirmed for all file, volume, snapshot, or appliance events. Scheduled polling, incremental API retrieval, manifests, and controlled file drops are therefore practical change-detection approaches.

Martini implementation pattern

Martini implementation pattern: a scheduler starts a workflow that retrieves only the relevant interval or resource set, compares stable identifiers and timestamps with stored checkpoints, applies business rules, and emits downstream updates or operational alerts.

Implementation sequence

Start the workflow on a controlled schedule
Load the previous checkpoint and processing boundaries
Poll the supported API or inspect the controlled file location
Select new or changed items using identifiers and timestamps
Process each item with idempotent target updates
Persist the new checkpoint and monitor exceptions

Common Nasuni integration patterns

Pattern 1: Synchronize Nasuni inventory to a CMDB

When to use this pattern

Use this pattern when infrastructure teams need current information about Edge Appliances, Volumes, Shares, Snapshots, or operational status in a CMDB or reporting database. It is appropriate when the required resources are enabled in the applicable NMC or appliance API.

Integration direction
Nasuni
Martini
ServiceNow
Example Mapping
Nasuni FieldCanonical FieldTarget Field
resource identifiersourceResourceIdexternal_id
resource namedisplayNamename
statuslifecycleStatusinstall_status
last updated timestampsourceUpdatedAtu_source_updated_at
Martini implementation pattern

A scheduled Martini workflow calls the relevant Nasuni endpoints, follows pagination or continuation behavior, normalizes resource types, and applies upsert rules keyed by the Nasuni resource identifier. It records checkpoints after successful pages, limits concurrency, retries transient failures, and routes permission or schema errors for review.

Martini capabilities used
  • workflows
  • scheduled triggers
  • API consumption
  • JSON handling
  • data mapping
  • business rules
  • checkpointing
  • error handling

Pattern 2: Process a Nasuni file manifest

When to use this pattern

Use this pattern when a producer places a manifest and related files in a Nasuni-accessible share and does not provide a suitable API or callback. A completion marker or manifest helps prevent processing files that are still being written.

Integration direction
Nasuni
Martini
Jira
Example Mapping
Nasuni FieldCanonical FieldTarget Field
file pathsourcePathattachment_source_path
file namefileNamesummary
modification timestampsourceModifiedAtsource_updated_at
manifest statusprocessingStatusstatus
Martini implementation pattern

Martini detects the controlled manifest, verifies that referenced files are complete and accessible, validates paths and metadata, and transforms each item into a Jira issue or another target payload. It uses path and modification metadata for idempotency, skips temporary files, and retries transient network or target-system errors.

Martini capabilities used
  • workflows
  • file processing
  • data validation
  • data mapping
  • business rules
  • idempotency
  • error handling

Pattern 3: Monitor Nasuni appliance and volume health

When to use this pattern

Use this pattern when operations teams need incidents or remediation tasks from Nasuni appliance, Volume, or Snapshot status. Because universal event notifications were not confirmed, scheduled polling is the safer baseline.

Integration direction
Nasuni
Martini
ServiceNow
Example Mapping
Nasuni FieldCanonical FieldTarget Field
appliance or volume identifierresourceKeycmdb_ci
operational statushealthStatusstate
status detaildiagnosticMessagedescription
snapshot timestampobservedAtwork_notes
Martini implementation pattern

A scheduled workflow polls supported management endpoints, classifies statuses against configured severity rules, and creates or updates ServiceNow incidents using a stable source key. Martini suppresses duplicate alerts, applies bounded retries and backoff, and records failed resource checks for the next run.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • conditional routing
  • business rules
  • data mapping
  • deduplication
  • monitoring
  • retry handling

Pattern 4: Expose a normalized Nasuni inventory API

When to use this pattern

Use this pattern when multiple internal applications need a stable interface but should not each depend on Nasuni API versions, permissions, or resource representations.

Integration direction
Nasuni
Martini
Enterprise applications
Example Mapping
Nasuni FieldCanonical FieldTarget Field
Nasuni resource identifieridid
resource typeresourceTypetype
resource statusstatusstatus
source timestamplastSynchronizedAtlastSynchronizedAt
Martini implementation pattern

Martini periodically retrieves and normalizes Nasuni resources, stores or caches the canonical representation, and exposes a controlled REST API for approved consumers. The workflow isolates API-version differences, validates fields before publication, applies authorization to the façade, and reports stale or failed synchronization states.

Martini capabilities used
  • API consumption
  • REST API exposure
  • workflows
  • data transformation
  • validation
  • authentication and authorization
  • error handling

Applications commonly integrated with Nasuni

Nasuni can participate in storage, identity, monitoring, governance, and recovery architectures. The following applications represent documented or conservative enterprise integration patterns; the exact direction and supported configuration should be confirmed for each deployment.

Application Scenario Direction Martini Pattern
Amazon S3 Amazon S3 can provide cloud object storage capacity within a Nasuni deployment architecture, subject to the supported customer configuration. Nasuni → Martini → Amazon S3 Martini can orchestrate metadata or control-file exchanges around the configured storage architecture, validate object-related information, and route status or inventory data to downstream systems without assuming direct access to Nasuni internal storage.
Microsoft Azure Blob Storage Azure Blob Storage can provide cloud storage capacity for organizations operating Nasuni with Azure infrastructure. Nasuni → Martini → Microsoft Azure Blob Storage Martini can coordinate supported API or file-based workflows around the deployment, apply environment-specific rules, and record processing checkpoints for operational or migration workflows.
Google Cloud Storage Google Cloud Storage can provide cloud object storage capacity for Nasuni deployments using Google Cloud. Nasuni → Martini → Google Cloud Storage Martini can process manifests, metadata, or operational responses associated with the deployment and send normalized results to cloud services or enterprise applications through APIs and workflows.
Microsoft Active Directory Active Directory can centralize identity and authorization for users accessing Nasuni volumes and shares. Microsoft Active Directory → Martini → Nasuni Martini can orchestrate approved identity or administrative workflows using configured credentials and APIs, while leaving authorization enforcement to the Nasuni and directory configuration.
ServiceNow Nasuni appliance, volume, or snapshot status can be normalized into incidents, configuration records, or operational work items. Nasuni → Martini → ServiceNow A scheduled Martini workflow polls supported Nasuni management resources, applies status and severity rules, de-duplicates by stable resource identifiers, and creates or updates ServiceNow records.
Jira Jira can receive operational or remediation issues when a Nasuni monitoring workflow detects a problem. Nasuni → Martini → Jira Martini can poll appliance or volume status, map normalized findings to Jira issue fields, avoid duplicate issues using source identifiers, and retry transient API failures.
Veeam Veeam may participate in protection and recovery processes involving enterprise file data, subject to product compatibility and deployment design. Nasuni → Martini → Veeam Martini can coordinate supported control or notification exchanges, validate backup-related status, and route exceptions for operational follow-up without assuming an undocumented native integration.

How to build a Nasuni integration in Martini

Objective

Confirm whether the integration uses an NMC API, appliance API, SMB or NFS access, S3-compatible access, or a controlled file exchange, then configure network reachability and credentials.

Instructions in Martini

  • Confirm the Nasuni component, API version, base URL, enabled resources, and permissions.
  • Keep management credentials separate from file-access credentials.
  • Store credentials and tokens in Martini environment secrets.
  • Confirm TLS, DNS, firewall, VPN, and file-share reachability.

Objective

Select the most specific reliable trigger available for the deployment rather than assuming that all Nasuni changes produce webhook events.

Instructions in Martini

  • Use a confirmed callback only when the customer documentation establishes the required event coverage.
  • Otherwise use a scheduler, incremental API polling, manifest, or controlled file-drop pattern.
  • Define the processing interval, checkpoint, and concurrency limits.

Objective

Retrieve Nasuni administrative resources, files, folders, or manifests through the selected supported interface while accounting for large inventories and file consistency.

Instructions in Martini

  • Call the applicable REST endpoint or inspect the controlled file location.
  • Handle pagination, continuation tokens, or bounded batches where available.
  • Check for locked, temporary, partial, or still-changing files.
  • Capture stable identifiers, timestamps, and source metadata.

Objective

Use a Martini workflow to coordinate retrieval, validation, transformation, target writes, checkpoints, and exception paths as one maintainable integration process.

Instructions in Martini

  • Separate retrieval, validation, transformation, delivery, and checkpoint stages.
  • Use conditional routing for resource types, statuses, paths, or file extensions.
  • Keep management-plane processing separate from file-content processing when appropriate.
  • Make each stage observable and safe to retry.

Objective

Normalize Nasuni-specific resource representations and file metadata into a canonical model suitable for target applications.

Instructions in Martini

  • Map resource identifiers, names, statuses, timestamps, paths, and metadata explicitly.
  • Handle optional or permission-dependent fields without assuming they are always present.
  • Apply validation before sending data downstream.
  • Use transformation rules for JSON, manifests, and other supported file formats.

Objective

Apply operational and governance rules before writing to target systems, including filtering, severity classification, deduplication, and processing eligibility.

Instructions in Martini

  • Select required Volumes, paths, extensions, or modification windows.
  • Use stable source identifiers for idempotency.
  • Apply status-to-severity or status-to-action rules.
  • Reject incomplete data and route it to an exception path.

Common Nasuni data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
VolumesRepresent logical Nasuni file-system containers that hold file data and metadata.CMDBs, governance platforms, reporting databases, monitoring systemsMartini retrieves Volumes through supported management APIs where available, validates identifiers and status, and performs checkpointed upserts.
Edge AppliancesRepresent appliance instances that provide local file access and communicate with the global file system.CMDBs, monitoring platforms, ServiceNow, JiraMartini polls supported appliance resources, normalizes health and deployment attributes, and routes exceptions using business rules.
SnapshotsRepresent point-in-time versions used for recovery, protection, and historical access.Monitoring platforms, backup operations, governance systemsMartini maps snapshot identifiers, timestamps, and status where exposed, using idempotency keys to prevent duplicate alerts or records.
SharesRepresent SMB, NFS, or other configured access points through which applications and users access volumes.CMDBs, access-governance systems, operational databasesMartini can synchronize share metadata through the applicable API or process share-based manifests when direct file access is configured.
Files and foldersRepresent the unstructured content hierarchy stored in Nasuni Volumes.Governance platforms, search systems, data warehouses, downstream file-processing applicationsMartini can process accessible files or manifests, apply path, extension, and modification-window rules, and handle incomplete or locked files conservatively.
Nasuni Management Console resourcesRepresent administrative resources such as configuration, users, operational status, appliances, and Volumes.CMDBs, reporting databases, monitoring platforms, administrative portalsMartini consumes the relevant NMC resources, maps version-dependent JSON fields to a canonical model, and exposes normalized APIs when useful.

Authentication and security considerations

Deployment-specific authentication

Nasuni authentication depends on the interface. NMC access uses configured users and authentication mechanisms, while directory services such as Microsoft Active Directory or LDAP can support identity and access management. File protocols and S3-compatible access use the permissions configured for the deployment.

Protect integration credentials

Store Nasuni API credentials, tokens, and file-access secrets in Martini environment configuration or secrets management rather than embedding them in workflows. Keep management-plane credentials separate from file-access credentials.

Control data exposure

  • Use TLS for API communication and approved private network paths where available.
  • Restrict API users and file identities to the resources required by the workflow.
  • Avoid writing credentials, tokens, or sensitive file content to logs.
  • Confirm permissions for each NMC or appliance API resource before deployment.

Operational considerations for Nasuni integrations

API versions and permissions

Confirm whether the workflow uses an NMC API or appliance API, including its version, base URL, enabled resources, roles, and permission model. Resource names and response fields may differ between components.

Large inventories

Use pagination or continuation behavior where available, incremental processing, durable checkpoints, bounded concurrency, and retry-safe page handling. Avoid repeatedly scanning an entire file system when a manifest or incremental query is available.

File consistency

SMB and NFS workflows must account for locks, temporary files, partial uploads, rename-based publishing, permission failures, and network interruptions. A producer-controlled completion marker or manifest is safer than processing every new file immediately.

Reliability and change management

  • Use stable source identifiers and upserts to prevent duplicates.
  • Back off after transient failures and route permanent errors for review.
  • Validate optional and permission-dependent fields before target writes.
  • Test API-version changes, schema variations, file edge cases, and network failures before production deployment.

Why use Martini instead of scripts or point-to-point integrations?

Centralized orchestration

Martini coordinates Nasuni API calls, file processing, transformations, target writes, checkpoints, and exception handling in reusable workflows rather than distributing logic across scripts.

Adaptable integration design

Nasuni deployments can differ in API component, resource availability, network topology, file protocols, and permissions. Martini can isolate those differences behind mappings, validation, business rules, and controlled APIs.

Operational reliability

  • Use scheduled, incremental, or event-driven patterns when a confirmed callback exists.
  • Apply idempotency, retries, bounded concurrency, and durable checkpoints.
  • Monitor workflow execution and route failures without exposing sensitive credentials or file content.
  • Expose a normalized REST API so downstream applications do not need to depend directly on Nasuni API versions.

Frequently asked questions

How can Nasuni be integrated with enterprise systems?

Nasuni can be integrated through its Nasuni Management Console and appliance REST APIs, configured SMB or NFS access, S3-compatible access where enabled, and controlled file or manifest exchanges. Scheduled polling and checkpointed processing are appropriate when webhook coverage is unavailable or unconfirmed.

Can Martini integrate with Nasuni?

Yes. Martini can consume the applicable Nasuni REST APIs, process accessible files through configured interfaces, transform JSON and file metadata, apply business rules, and write normalized data to enterprise applications or databases.

Do I need a connector to integrate Nasuni with Martini?

No. A dedicated Nasuni connector is not required. Martini can use Nasuni's confirmed REST APIs, configured file or object-access interfaces, authentication mechanisms, scheduled polling patterns, and controlled file exchanges.

Is there any extra Lonti cost to integrate Nasuni with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Nasuni. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Nasuni, cloud storage providers, network infrastructure, or other third-party systems depending on subscription, usage, and deployment model.

Which Nasuni integration methods should architects use?

REST APIs are the primary option for management and administrative resources. File-oriented workflows can use configured SMB, NFS, S3-compatible, or shared-volume access where appropriate. GraphQL, SOAP, generalized webhook coverage, and standard bulk APIs were not confirmed and should not be assumed.

Are Nasuni webhooks or event notifications available?

General webhook coverage for all file, Volume, Snapshot, and appliance events was not confirmed. Martini can receive a callback when the customer confirms a supported Nasuni event mechanism; otherwise scheduled API polling, manifests, or controlled file drops should be used.

How does synchronization with Nasuni work?

A Martini workflow can poll supported management resources, process manifests or accessible files, compare identifiers and timestamps with stored checkpoints, and perform idempotent upserts. Large inventories should use pagination, incremental processing, bounded concurrency, and retry-safe checkpoints.

How does Martini handle Nasuni mapping, errors, and duplicate data?

Martini maps Nasuni resource and file metadata into canonical target models, validates required fields, and applies business rules before delivery. Stable resource identifiers, snapshot identifiers, or path and modification metadata can support idempotency, while retries, backoff, exception routes, and workflow monitoring handle transient and permanent failures.

Related Martini documentation

Nasuni APIs

Workflows

Data processing

Security

Operations

Connect Nasuni to your enterprise systems

Use Martini to orchestrate Nasuni APIs, file-oriented workflows, data transformations, and operational synchronization with the systems your organization relies on.

EXPLORE MARTINI
BOOK A DEMO