.png)
NetSuite OpenAir Integration Guide
NetSuite OpenAir integrates with enterprise systems through REST APIs, XML or SOAP-style interfaces, scheduled synchronization, and selected account-specific notifications.
NetSuite OpenAir integration options at a glance
NetSuite OpenAir provides REST APIs for supported customers, projects, users, resources, time, expenses, invoices, and related operations. XML or SOAP-style interfaces may remain relevant for legacy integrations or capabilities not available through REST, but the specific endpoint and operations should be verified. OpenAir does not provide a universal event stream; selected account or module notifications may be available, while scheduled incremental retrieval is the more predictable synchronization pattern. Martini can consume these APIs, manage OAuth 2.0 or API-specific credentials, transform JSON or XML, orchestrate dependencies, expose controlled APIs, and implement pagination, batching, checkpointing, retries, and reconciliation.
| Integration point | Supported by NetSuite OpenAir? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Request/response access to supported Customers, Projects, Tasks, Users, Resources, time, expenses, invoices, and other OpenAir operations. REST is the preferred starting point for new integrations when the required operation is available. | Martini can consume the OpenAir REST API, transform payloads, apply business rules, orchestrate dependent calls, and expose a separate Martini API for downstream consumers. |
| SOAP/XML APIs | Limited | Existing enterprise integrations or operations that remain available through OpenAir XML or SOAP-style interfaces. The exact protocol, endpoint, and supported operations must be verified. | Martini can consume documented SOAP services and XML-based interfaces, manage API-specific credentials, map XML payloads, and handle protocol-specific errors. |
| Webhooks / outbound callbacks | Limited | Selected account- or module-specific notifications may provide event-driven processing, but OpenAir should not be assumed to expose notifications for every object or lifecycle event. | Martini can receive a confirmed callback, validate and deduplicate the notification, retrieve the current OpenAir resource, and invoke the downstream workflow. |
| Bulk, asynchronous, or batch operations | Limited | Selected APIs may support batch or multi-object behavior for larger transfers. Object coverage, transaction limits, and semantics require account-specific verification. | Martini can control page and batch sizes, sequence dependent operations, checkpoint progress, and retry only failed or retryable work. |
| File and attachment APIs | Limited | Document and attachment operations may be available for objects such as Expense Reports or project documents, subject to API version, file type, limits, and account configuration. | Martini can retrieve or submit supported files, transform metadata, route binary content through workflows, and record the related OpenAir object and correlation identifier. |
| Scheduled synchronization | Yes | Polling is appropriate when universal change events are unavailable. Modified-date, timestamp, status, or identifier filters can support incremental retrieval where exposed by the selected API. | Martini scheduler-triggered workflows can maintain watermarks, paginate results, apply approval-state filters, and reconcile completed batches. |
| Authentication | Yes | REST integrations can use OAuth 2.0 bearer tokens where enabled. XML or SOAP-style integrations may use OpenAir API credentials and account-specific permissions. | Martini can reference secrets and environment configuration for tokens, credentials, account context, and endpoint settings without embedding them in workflows or payloads. |
| Direct database access | No | Direct access to the OpenAir production database is not a standard integration method. Supported APIs and vendor-provided export or reporting mechanisms should be used instead. | Martini should consume supported OpenAir endpoints or files rather than attempting a direct connection to the SaaS database. |
How NetSuite OpenAir exposes data and business events
NetSuite OpenAir REST APIs
OpenAir REST APIs provide programmatic request/response access to supported business objects and operations. Availability varies by account enablement, API version, permissions, and object coverage.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates with the configured OpenAir REST credentials, retrieves or submits the required resource, maps JSON data into a canonical model, applies validation and business rules, and writes the result to the target system. Scheduled workflows are used when incremental polling is more reliable than event notifications.
Implementation sequence
NetSuite OpenAir SOAP/XML APIs
OpenAir has historically provided XML-based interfaces, including SOAP-style APIs. These may remain relevant for existing integrations or operations unavailable through REST, but the protocol and endpoint must be verified for the account.
Martini implementation pattern
Martini implementation pattern: a workflow consumes the confirmed SOAP or XML endpoint, supplies account-specific credentials, parses the response, maps XML elements to the canonical model, and classifies transport, authentication, validation, and vendor business errors.
Implementation sequence
Selected OpenAir callbacks
OpenAir should not be treated as a universal webhook provider. Selected account or module notifications may be available, while event coverage and lifecycle support must be confirmed before implementation.
Martini implementation pattern
Martini implementation pattern: Martini receives a confirmed callback, authenticates and validates the request, deduplicates the notification, retrieves the current OpenAir object when necessary, and invokes the downstream workflow. Scheduled reconciliation remains important for missed or unsupported events.
Implementation sequence
Scheduled OpenAir synchronization
Scheduled retrieval is the dependable pattern when OpenAir does not expose the required event. Modified-date, timestamp, status, or identifier filters can reduce repeated full loads where supported.
Martini implementation pattern
Martini implementation pattern: a scheduler starts a workflow that loads the last successful watermark, retrieves paginated OpenAir data, filters by approval or lifecycle state, transforms each object, and persists a new checkpoint only after successful processing.
Implementation sequence
OpenAir batch and attachment operations
Batch, multi-object, file, and attachment operations may be available for selected APIs and objects. Transaction limits, file types, encoding, and supported operations must be confirmed before use.
Martini implementation pattern
Martini implementation pattern: a workflow divides work into bounded batches, sequences object dependencies, transfers supported attachment content, records per-item outcomes, and retries only transient failures. The workflow can fall back to individual operations when batch behavior is unavailable.
Implementation sequence
Common NetSuite OpenAir integration patterns
Pattern 1: Create OpenAir projects from CRM opportunities
When to use this pattern
Use this pattern when a closed-won opportunity in Salesforce or another CRM should create a Customer and Project in OpenAir. It is useful when project initiation depends on validated customer ownership, project templates, billing rules, and duplicate prevention.
Integration direction
Example Mapping
| NetSuite OpenAir Field | Canonical Field | Target Field |
|---|---|---|
| Opportunity.accountId | customer.externalId | Customer.externalId |
| Opportunity.name | project.name | Project.name |
| Opportunity.closeDate | project.startDate | Project.startDate |
| Opportunity.amount | project.billingAmount | Project.billingAmount |
Martini implementation pattern
Martini receives the opportunity through an API or scheduled retrieval, validates required customer and project fields, matches or creates the OpenAir Customer, and then creates the Project. Business rules determine project template, billing attributes, and ownership. The workflow stores returned identifiers and routes duplicate or validation failures to exception handling without creating a second project.
Martini capabilities used
- API consumption
- API exposure
- workflows
- data mapping
- business rules
- error handling
Pattern 2: Synchronize approved OpenAir time and expenses
When to use this pattern
Use this pattern when approved Timesheets, time entries, or Expense Reports must be sent to payroll, ERP, or financial applications. Approval state and corrected-entry reprocessing are central to this design.
Integration direction
Example Mapping
| NetSuite OpenAir Field | Canonical Field | Target Field |
|---|---|---|
| timeEntry.userId | worker.externalId | Worker.id |
| timeEntry.projectId | project.externalId | ProjectReference.id |
| timeEntry.hours | time.quantity | TimeEntry.hours |
| expenseReport.total | expense.amount | Expense.amount |
Martini implementation pattern
A scheduled workflow retrieves recently modified approved data using an OpenAir filter where available. Martini validates employee, project, task, currency, and accounting references, maps time and expense structures, and submits them to the target application. Stable source identifiers make retries idempotent, while rejected or corrected entries remain available for replay and reconciliation.
Martini capabilities used
- scheduled workflows
- API consumption
- incremental synchronization
- data mapping
- validation
- retry handling
Pattern 3: Synchronize OpenAir project accounting with NetSuite ERP
When to use this pattern
Use this pattern when OpenAir and NetSuite ERP share responsibility for Customers, Projects, invoices, expenses, or project financial data. It requires clear ownership, accounting-period rules, and identifier mappings.
Integration direction
Example Mapping
| NetSuite OpenAir Field | Canonical Field | Target Field |
|---|---|---|
| Project.customerId | customer.externalId | Customer.internalId |
| Project.id | project.externalId | Project.externalId |
| Invoice.status | invoice.lifecycleStatus | Invoice.status |
| ExpenseReport.currency | expense.currency | Expense.currency |
Martini implementation pattern
Martini runs object-specific workflows in either direction according to system-of-record rules. It validates accounting periods and subsidiaries, transforms currencies and identifiers, applies upsert or update rules where supported, and checkpoints successful pages. Transient API failures are retried with backoff, while accounting or validation conflicts are retained for review.
Martini capabilities used
- workflows
- API orchestration
- data transformation
- business rules
- checkpointing
- error handling
Pattern 4: Publish OpenAir project and resource status
When to use this pattern
Use this pattern when planning, reporting, service-management, or collaboration applications need selected OpenAir Projects, Tasks, Resources, or status data. It is appropriate when downstream consumers need a controlled model rather than direct OpenAir access.
Integration direction
Example Mapping
| NetSuite OpenAir Field | Canonical Field | Target Field |
|---|---|---|
| Project.status | engagement.status | ServiceNow.status |
| Task.name | workItem.name | ServiceNow.taskName |
| Resource.id | resource.externalId | ServiceNow.resourceReference |
| Project.modifiedDate | source.modifiedAt | ServiceNow.sourceModifiedAt |
Martini implementation pattern
Martini retrieves changed OpenAir objects on a schedule or processes a confirmed notification, filters sensitive resource fields, normalizes status values, and exposes or submits a downstream API payload. Correlation identifiers, incremental watermarks, and reconciliation protect against duplicate or missed updates.
Martini capabilities used
- scheduled workflows
- API exposure
- API consumption
- field filtering
- mapping and transformation
- monitoring
Applications commonly integrated with NetSuite OpenAir
NetSuite OpenAir can be integrated with adjacent business applications when project, resource, time, expense, billing, or reporting data must cross system boundaries. The exact direction and ownership of each object should be defined for the customer account and enabled OpenAir APIs.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| NetSuite ERP | Synchronize customers, projects, invoices, expenses, and project accounting information across OpenAir and the broader NetSuite environment. | NetSuite OpenAir → Martini → NetSuite ERP | Use REST APIs where available, with controlled bidirectional workflows for objects owned by each system. Martini validates dependencies, maps identifiers and accounting attributes, applies idempotency keys, and routes failures for retry or reconciliation. |
| Salesforce | Create OpenAir Customers and Projects from won Opportunities and return project, delivery, or billing status to the CRM. | Salesforce → Martini → NetSuite OpenAir | Expose or consume a Salesforce API, validate the customer and opportunity payload, map it to OpenAir Customers and Projects, and return vendor identifiers. Use duplicate checks, dependency sequencing, and exception handling for rejected project creation. |
| Workday | Exchange worker, organization, payroll, or approved time information between HR operations and professional-services delivery. | Workday → Martini → NetSuite OpenAir | Retrieve or receive approved worker and time data, normalize employee and organization identifiers, validate project and task references, and write only records meeting the configured approval and accounting rules. |
| SAP S/4HANA | Synchronize project financials, customers, invoices, expenses, and accounting data between OpenAir and an enterprise finance platform. | NetSuite OpenAir → Martini → SAP S/4HANA | Implement object-specific workflows with explicit system-of-record rules, currency and subsidiary mappings, incremental retrieval, idempotent updates, and retry handling for transient finance-system failures. |
| ServiceNow | Connect project delivery information with service engagements, requests, and operational workflows. | NetSuite OpenAir → Martini → ServiceNow | Retrieve selected Projects, Tasks, or status data from OpenAir, normalize lifecycle values, and submit controlled updates to ServiceNow through its APIs. Apply filtering and privacy rules before publishing resource or customer information. |
| Jira | Align OpenAir project or task status with engineering and delivery work items. | NetSuite OpenAir → Martini → Jira | Use scheduled incremental retrieval or a confirmed callback, map project and task identifiers to Jira work items, apply status translation rules, and record correlation identifiers to prevent duplicate updates. |
| Expensify | Move expense data into OpenAir for project allocation, approval, or billing processes. | Expensify → Martini → NetSuite OpenAir | Consume the available expense export or API, validate employee, project, task, currency, and category references, then submit supported OpenAir expense operations with stable source identifiers and replay handling. |
| Microsoft Power BI | Publish OpenAir project, time, expense, and financial data for utilization and delivery reporting. | NetSuite OpenAir → Martini → Microsoft Power BI | Retrieve approved or recently modified OpenAir data, transform it into a reporting model, apply privacy and status filters, and deliver it through the selected Power BI ingestion method with checkpointed batches. |
How to build a NetSuite OpenAir integration in Martini
Objective
Establish the OpenAir account, endpoint, permissions, and authentication configuration for the selected API.
Instructions in Martini
- Confirm the enabled OpenAir API, account context, endpoint, object coverage, and permissions.
- Store OAuth tokens or API-specific credentials in Martini secrets and externalize environment-specific values.
- Use HTTPS and avoid placing credentials in payloads, source code, or logs.
Objective
Select an event, callback, API request, or scheduled trigger based on the actual OpenAir event coverage.
Instructions in Martini
- Use a confirmed callback only for supported account or module events.
- Use a scheduler for incremental retrieval when universal event coverage is unavailable.
- Define the object, lifecycle state, modified-time filter, and expected processing frequency.
Objective
Collect OpenAir data efficiently and safely from REST, XML, SOAP-style, batch, or attachment operations.
Instructions in Martini
- Retrieve pages using supported pagination and incremental filters.
- Respect account limits with bounded concurrency and controlled batch sizes.
- Persist a watermark, source identifier, or cursor only after successful processing.
Objective
Coordinate dependent operations such as Customers before Projects and Projects before Tasks or time entries.
Instructions in Martini
- Validate parent-object dependencies before writing child objects.
- Separate retryable transport or throttling failures from non-retryable business errors.
- Use reusable workflow logic for common authentication, mapping, and exception handling.
Objective
Convert OpenAir JSON or XML structures into canonical and target-system models.
Instructions in Martini
- Map actual OpenAir Customers, Projects, Tasks, Users, Resources, time, expense, and invoice fields.
- Normalize statuses, currencies, dates, identifiers, and approval states.
- Handle optional and account-specific fields without assuming every tenant has the same schema.
Objective
Ensure only valid, approved, and correctly sequenced data is transferred.
Instructions in Martini
- Require approved status before exporting time or expense data when applicable.
- Apply duplicate prevention using stable source identifiers or correlation keys.
- Enforce project, task, customer, employee, currency, and accounting-period rules.
Common NetSuite OpenAir data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Customers | Organizations or clients associated with projects, billing, and customer-facing delivery. | NetSuite ERP, Salesforce, SAP S/4HANA | Martini matches stable customer identifiers, validates required attributes, sequences customer creation before dependent Projects, and applies duplicate-prevention rules. |
| Projects | Professional-services engagements containing schedule, delivery, financial, and billing information. | Salesforce, NetSuite ERP, SAP S/4HANA, Jira, ServiceNow | Martini maps project ownership, customer references, status, dates, and billing attributes, then orchestrates dependent Tasks and reconciliation. |
| Tasks | Work units associated with Projects and used for planning and time allocation. | Jira, ServiceNow, reporting platforms, payroll or finance applications | Martini validates the parent Project and task identifiers, normalizes status and hierarchy, and prevents updates against missing dependencies. |
| Users | OpenAir users, employees, consultants, or other personnel participating in delivery and time processes. | Workday, NetSuite ERP, SAP S/4HANA, payroll applications | Martini maps employee and user identifiers, filters permitted attributes, and applies account-specific role and privacy rules. |
| Resources | Personnel or other resources used for project staffing, allocation, and utilization. | Workday, planning applications, reporting platforms, ServiceNow | Martini transforms resource availability, allocation, and status data, applies privacy controls, and publishes only the fields required by downstream systems. |
| Timesheets / time entries | Submitted or approved time recorded against Projects and Tasks. | Workday, payroll applications, NetSuite ERP, SAP S/4HANA | Martini retrieves approved or recently modified entries, maps employees, projects, tasks, currency, and accounting attributes, and uses stable source IDs for idempotent processing. |
Authentication and security considerations
Authentication and account access
REST integrations can use OAuth 2.0 bearer tokens where enabled for the OpenAir account. XML or SOAP-style integrations may use OpenAir API credentials and account-specific access configuration.
- Store tokens, credentials, endpoints, and account context in Martini secrets or environment configuration.
- Use HTTPS for API communication and restrict the OpenAir integration identity to required objects and operations.
- Confirm account enablement, role permissions, API version, and feature availability before implementation.
- Do not expose credentials in workflow payloads, source code, logs, or downstream error messages.
Operational considerations for NetSuite OpenAir integrations
Reliability and lifecycle controls
OpenAir account configuration, enabled modules, custom fields, permissions, API limits, and object schemas can vary. Integration designs should verify the selected API and test representative Customers, Projects, Tasks, Users, Resources, time, expense, and invoice scenarios.
- Use pagination, modified-date or status filters, watermarks, and bounded concurrency for large collections.
- Handle HTTP 429 or equivalent throttling responses with exponential backoff and controlled batch sizes.
- Use stable source identifiers and correlation keys to make creates and updates idempotent.
- Respect approval states before exporting Timesheets or Expense Reports.
- Classify retryable transport errors separately from validation, permission, and accounting errors.
- Monitor schema changes, reconcile source and target counts, and retain sufficient response details for replay without exposing sensitive data.
Why use Martini instead of scripts or point-to-point integrations?
Maintainable integration orchestration
Direct scripts can become difficult to govern when an OpenAir integration must coordinate Customers, Projects, Tasks, resources, time, expenses, invoices, and dependent financial systems. Martini provides a structured environment for workflows, APIs, mappings, transformations, business rules, and operational handling.
- Centralize authentication and environment-specific configuration rather than duplicating credentials across scripts.
- Reuse workflow logic for pagination, checkpoints, validation, retries, and reconciliation.
- Expose a controlled API façade so downstream systems do not depend directly on OpenAir account details.
- Separate vendor-specific payloads from canonical enterprise models through explicit mappings.
- Use workflow logs, error handling, and monitoring to support troubleshooting and controlled replay.
Frequently asked questions
NetSuite OpenAir can be integrated through its REST APIs, selected XML or SOAP-style interfaces, scheduled incremental retrieval, and limited account- or module-specific callbacks. The appropriate method depends on the OpenAir API version, enabled features, permissions, and required object operations.
Yes. Martini can integrate with NetSuite OpenAir by consuming its REST APIs, supported XML or SOAP-style interfaces, and confirmed callbacks. Martini can orchestrate workflows, map OpenAir objects, expose controlled APIs, and implement scheduled synchronization when event coverage is insufficient.
No. A dedicated NetSuite OpenAir connector is not required. Martini can use OpenAir's confirmed native REST, XML, SOAP-style, callback, and authentication mechanisms through standards-based API consumption and workflow orchestration.
Lonti does not charge an additional per-connector or per-vendor fee to integrate NetSuite OpenAir. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Oracle NetSuite, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
Use the OpenAir REST API when it supports the required object and operation. Consider an XML or SOAP-style API for an existing implementation or a capability unavailable through REST, after verifying the endpoint, protocol, account enablement, and supported operations.
OpenAir should not be treated as providing a universal webhook or change-event stream. Selected account or module notifications may be available, but coverage must be confirmed. Otherwise, Martini can use scheduled workflows with modified-time, status, or identifier filters and reconciliation.
Martini can retrieve paginated and incrementally filtered Customers, Projects, Tasks, Users, Resources, time, expenses, or invoices, transform them into target models, and store checkpoints. Idempotent identifiers, approval-state rules, dependency sequencing, retries, and reconciliation help manage duplicates and corrected data.
Yes. Martini can expose a controlled API that hides OpenAir credentials and account-specific details from downstream consumers. The API can validate requests, invoke OpenAir REST or XML/SOAP operations, apply mappings and business rules, and return a stable enterprise-facing model.
Related Martini documentation
APIs
Integrate NetSuite OpenAir with confidence
Use Martini to connect NetSuite OpenAir with enterprise applications through governed APIs, scheduled workflows, mappings, business rules, and reliable operational controls.