Ellipse Gradient for Header

Zip Integration Guide

Connect Zip procurement workflows with enterprise applications through REST APIs, selected webhook events, scheduled synchronization, and secure API-key authentication.

Zip integration options at a glance

Zip’s primary integration mechanism is its REST API, which supports access to procurement Requests, Approvals, Purchase Orders, Vendors, Invoices, and Users. Zip also supports webhook-style notifications for selected objects or lifecycle events, although coverage must be confirmed for each tenant and use case. API-key authentication is documented for programmatic access. Where webhooks are unavailable, Martini can run scheduled workflows that retrieve paginated data, maintain synchronization checkpoints, apply validation and business rules, and map Zip payloads to ERP, HR, finance, identity, or collaboration applications. Bulk, general-purpose attachment, GraphQL, SOAP, and direct database interfaces were not confirmed.

Integration pointSupported by Zip?Common use casesHow Martini supports it
REST APIsYesZip’s primary confirmed integration mechanism for creating or updating Requests and retrieving Approvals, Vendors, Purchase Orders, Invoices, and Users. API version, fields, and operations should be verified for the target tenant.Martini can consume Zip REST endpoints from workflows, map request and response payloads, apply business rules, and expose an internal REST API that abstracts Zip-specific details.
Webhooks / outbound callbacksLimitedZip supports webhook-style notifications for selected objects or lifecycle events. Coverage is not universal and must be confirmed for each required event.Martini can expose a REST endpoint, validate and deduplicate notifications, acknowledge them quickly, and invoke asynchronous workflows for downstream processing.
AuthenticationYesZip documents API-key-based authentication, generally using a bearer token or API key in HTTP authorization headers. Permissions depend on the key, user, application, and tenant.Martini can store the key in Secrets Management, reference it from API configurations, separate environment credentials, and support controlled credential rotation.
Bulk / asynchronous APIsNot confirmedA dedicated Zip bulk or asynchronous API was not confirmed. High-volume synchronization should use pagination, incremental filters where available, checkpoints, and bounded concurrency.Martini can orchestrate scheduled, paginated REST calls, persist checkpoints, limit concurrency, and retry transient failures without assuming a bulk endpoint.
File / attachment APIsNot confirmedZip records may contain supporting documents, but a generally available standalone attachment API was not verified. Attachment endpoints and constraints require confirmation.Martini can transfer files or secure references when a documented Zip endpoint is available, subject to authorization, file-size, content-type, and retention requirements.
Database / analytics accessNoDirect Zip database access is not a normal integration mechanism. Integrations should use documented APIs or supported export and reporting facilities.Martini can connect to external databases when required by the surrounding architecture, but it should not be presented as connecting directly to Zip’s database.

How Zip exposes data and business events

Zip REST APIs

Zip’s REST API is the primary confirmed mechanism for programmatic access to procurement objects. It can support operations involving Requests, Approvals, Vendors, Purchase Orders, Invoices, and Users, subject to API version, tenant configuration, and permissions.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with a Zip API key held in Secrets Management, calls the required endpoint, validates the response, maps Zip fields to a canonical model, applies business rules, and writes the result to a target application or exposes it through a controlled Martini API.

Implementation sequence

Authenticate the request with a protected Zip API key
Call the required Zip REST endpoint
Handle pagination and persist the synchronization checkpoint
Validate the response and required business fields
Map Zip objects to the target application model
Apply approval, status, and idempotency rules

Zip webhook notifications

Zip supports webhook-style notifications for selected objects or lifecycle events. Event availability and coverage should be confirmed for each required Request, Approval, Purchase Order, Vendor, or Invoice lifecycle.

Martini implementation pattern

Martini implementation pattern: a Martini REST endpoint receives the notification, validates the request using the mechanism documented for the tenant, acknowledges quickly, deduplicates the event, and starts a workflow that retrieves current Zip state before updating downstream systems.

Implementation sequence

Receive the Zip webhook notification
Validate the notification and identify the Zip object
Acknowledge the request promptly
Deduplicate the event using its identifier or object correlation
Retrieve current Zip state when required
Map and process the object asynchronously

Scheduled Zip synchronization

Scheduled polling is appropriate for objects or lifecycle events that are not covered by Zip webhook notifications, and for reconciliation when webhook delivery is incomplete or unavailable.

Martini implementation pattern

Martini implementation pattern: a scheduled workflow queries paginated Zip REST endpoints using an overlap window or incremental filter, orders and checkpoints results, deduplicates late-arriving updates, and applies bounded concurrency and retry policies.

Implementation sequence

Start the workflow on a controlled schedule
Load the durable synchronization checkpoint
Request the next page of changed Zip objects
Apply overlap-window and duplicate handling
Map and write each valid object to the target system
Persist the new checkpoint and processing results

Common Zip integration patterns

Pattern 1: Synchronize HR users and approval structures

When to use this pattern

Use this pattern when Zip requesters, approvers, departments, cost centers, or managers must remain aligned with an HR or identity source. It supports scheduled synchronization and validation of organizational data before it affects procurement routing.

Integration direction
Workday
Martini
Zip
Example Mapping
Zip FieldCanonical FieldTarget Field
worker.idexternalUserIdUsers.external_id
worker.manager.idmanagerExternalIdUsers.manager_id
organization.cost_centercostCenterCodeUsers.cost_center
worker.activeisActiveUsers.status
Martini implementation pattern

Martini retrieves changed HR data, maps it to Zip Users and organizational attributes, validates identifiers and required fields, and applies create-or-update rules. Invalid records are recorded for review rather than repeatedly retried, while the checkpoint advances only after the page is safely processed.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • validation
  • business rules
  • error handling

Pattern 2: Convert approved Requests into ERP purchasing

When to use this pattern

Use this pattern when Zip is the procurement intake and approval layer while an ERP remains responsible for purchase requisitions or Purchase Orders. The workflow prevents downstream commitments before required Zip Approvals are complete.

Integration direction
Zip
Martini
NetSuite
Example Mapping
Zip FieldCanonical FieldTarget Field
Request.idprocurementRequestIdexternal_reference
Request.vendor_idsupplierIdvendor
Request.line_items[].amountlineAmountpurchase_order.lines[].amount
Approvals.statusapprovalStateworkflow_status
Martini implementation pattern

Martini receives a supported Zip event or polls for approved Requests, retrieves current Request and Approval data, validates supplier, currency, accounting, and line-item values, and transforms the result into the ERP model. It uses external references and reconciliation before retrying a timed-out create operation, then records the ERP identifier and status where Zip supports the update.

Martini capabilities used
  • webhook handling
  • scheduled workflows
  • API consumption
  • data mapping
  • business rules
  • idempotency
  • retry handling

Pattern 3: Synchronize suppliers and Purchase Order status

When to use this pattern

Use this pattern when the ERP is the financial system of record but Zip users need current supplier and purchasing status. It is suitable for bidirectional synchronization with explicit authority rules for each field.

Integration direction
NetSuite
Martini
Zip
Example Mapping
Zip FieldCanonical FieldTarget Field
vendor.internal_idsupplierIdVendors.external_id
vendor.payment_termspaymentTermsVendors.payment_terms
purchase_order.statuspurchaseOrderStatusPurchase Orders.status
purchase_order.numberpurchaseOrderNumberPurchase Orders.external_reference
Martini implementation pattern

A Martini scheduled workflow retrieves changed supplier and Purchase Order data, maps stable identifiers and status values to Zip, and checks whether the target object already reflects the source version. Conflicting updates are routed for review, transient HTTP failures use bounded retries, and successful writes update the checkpoint.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • business rules
  • idempotency
  • monitoring
  • error handling

Pattern 4: Reconcile Invoices with procurement commitments

When to use this pattern

Use this pattern when Zip Invoices must be coordinated with Purchase Orders and an ERP or finance platform. It supports amount, currency, supplier, duplicate, and approval-state controls before financial posting.

Integration direction
Zip
Martini
SAP S/4HANA
Example Mapping
Zip FieldCanonical FieldTarget Field
Invoice.idinvoiceIdinvoice.external_reference
Invoice.purchase_order_idpurchaseOrderIdinvoice.purchase_order_reference
Invoice.amountgrossAmountinvoice.amount
Invoice.currencycurrencyCodeinvoice.currency
Martini implementation pattern

Martini retrieves Invoices or processes supported invoice-related notifications, matches each Invoice to a Purchase Order and Vendor, validates amount and currency rules, and sends accepted data to the finance system. Duplicate invoices, missing purchase-order references, and approval-state conflicts are held as business exceptions rather than retried as transport failures.

Martini capabilities used
  • API consumption
  • webhook handling
  • data mapping
  • validation
  • business rules
  • duplicate detection
  • error handling

Applications commonly integrated with Zip

Zip can be integrated with adjacent enterprise applications to coordinate procurement intake, approvals, supplier data, purchasing, finance, user administration, and notifications. The exact objects and operations depend on the Zip tenant, API version, permissions, and the design of the surrounding application landscape.

Application Scenario Direction Martini Pattern
NetSuite Synchronize Zip Vendors, Purchase Orders, accounting dimensions, and invoice information with NetSuite purchasing and finance processes. Zip → Martini → NetSuite Martini can receive approved Zip Requests or poll them on a schedule, validate supplier and accounting data, transform the payload into NetSuite purchasing structures, and write identifiers and processing outcomes back to Zip where the relevant operation is available.
SAP S/4HANA Connect Zip procurement intake and approvals with SAP supplier, purchasing, and finance processes. Zip → Martini → SAP S/4HANA A Martini workflow can orchestrate approved Request and Vendor data between Zip and SAP S/4HANA, apply canonical mappings for suppliers and accounting dimensions, enforce approval-state rules, and route failures for operational review.
Workday Synchronize users, managers, departments, cost centers, and organizational structures used for Zip request routing and approvals. Workday → Martini → Zip Martini can retrieve changed Workday worker and organization data on a schedule, map it to Zip Users and organizational attributes, validate required identifiers, and isolate records that cannot be applied.
Salesforce Initiate procurement Requests from sales, customer-success, or operations processes and return procurement status to Salesforce. Salesforce → Martini → Zip Martini can expose or consume the required APIs, transform Salesforce business context into a Zip Request, correlate the Zip identifier with the source record, and send selected status updates back after approval or processing changes.
Slack Notify requesters and approvers about Requests, approval decisions, and procurement exceptions. Zip → Martini → Slack Martini can receive selected Zip webhook notifications or poll for state changes, format concise messages, apply notification rules, and call the relevant Slack endpoint while preventing duplicate notifications.
Jira Link procurement Requests to technology, facilities, or project work and synchronize fulfillment status. Jira → Martini → Zip A Martini workflow can accept a Jira request or issue event, create or update a Zip Request, retain cross-system identifiers, and synchronize approved or completed procurement status back to Jira.
Okta Support user lifecycle and access-management processes for Zip Users. Okta → Martini → Zip Martini can consume Okta lifecycle data, map active and inactive identities to Zip Users where supported, validate tenant permissions, and record exceptions for accounts requiring manual review.

How to build a Zip integration in Martini

Objective

Establish Zip API access with an environment-specific integration identity and keep credentials outside workflow logic.

Instructions in Martini

  • Confirm the Zip API version, tenant permissions, authorization header format, and required object scopes
  • Store the Zip API key in Martini Secrets Management
  • Configure separate credentials for development, testing, and production where permitted
  • Define target application credentials using the same environment-safe approach

Objective

Select an event-driven or scheduled entry point based on the Zip lifecycle event and its confirmed availability.

Instructions in Martini

  • Use a Martini API endpoint for selected Zip webhook notifications
  • Use a scheduler trigger for objects or events without webhook coverage
  • Define an overlap window and checkpoint strategy for polling
  • Separate interactive processing from reconciliation workloads

Objective

Obtain the current Zip object state rather than relying solely on a notification payload or a single page of results.

Instructions in Martini

  • Call the relevant Zip REST endpoint
  • Follow the documented pagination model and page-size limits
  • Retrieve current Requests, Approvals, Vendors, Purchase Orders, Invoices, or Users as required
  • Persist object and event identifiers needed for reconciliation

Objective

Coordinate validation, enrichment, target calls, status updates, and exception paths in a maintainable Martini workflow.

Instructions in Martini

  • Route the payload through reusable workflow logic
  • Correlate Zip identifiers with source and target identifiers
  • Separate transport failures from business-rule failures
  • Use bounded concurrency for scheduled synchronization

Objective

Transform Zip’s tenant-specific procurement structures into a canonical model and target application format.

Instructions in Martini

  • Map stable IDs instead of display labels where available
  • Validate suppliers, users, currency, amounts, accounting dimensions, and approval state
  • Apply canonical mappings for departments, locations, cost centers, entities, and GL accounts
  • Preserve source values needed for audit and replay

Objective

Apply validated changes to ERP, HR, identity, finance, collaboration, or work-management applications without creating duplicates.

Instructions in Martini

  • Use stable external references for create-or-update decisions
  • Write target identifiers and processing outcomes back to Zip where supported
  • Check for an existing target object before retrying a timed-out create request
  • Route conflicting or incomplete data to an exception process

Common Zip data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
RequestsEmployee or business-user procurement intake records that initiate purchasing workflows.NetSuite, SAP S/4HANA, Salesforce, JiraMartini can receive or retrieve Requests, validate requester, supplier, accounting, currency, and line-item data, map them to target models, and retain cross-system identifiers.
ApprovalsApproval steps, approvers, decisions, and approval state associated with procurement Requests.NetSuite, SAP S/4HANA, Slack, SalesforceMartini can evaluate approval state before creating financial commitments, route decision notifications, and distinguish Zip approval status from downstream processing status.
Purchase OrdersPurchasing commitments created after request and approval processing.NetSuite, SAP S/4HANA, finance applicationsMartini can synchronize Purchase Orders using stable external references, apply idempotency rules, and reconcile timed-out or duplicated create attempts.
VendorsSuppliers participating in procurement activity and supplier master-data synchronization.NetSuite, SAP S/4HANA, finance applicationsMartini can normalize supplier identifiers, payment terms, status, and address or accounting attributes before creating or updating target supplier records.
InvoicesSupplier invoices associated with purchasing and accounts-payable processes.NetSuite, SAP S/4HANA, finance applicationsMartini can match Invoices to Purchase Orders and Vendors, validate amount and currency rules, detect duplicates, and route accepted data to finance workflows.
UsersRequesters, approvers, and other participants in Zip procurement workflows.Workday, Okta, Microsoft Entra ID, SalesforceMartini can synchronize user and organizational data, apply lifecycle and permission rules, and isolate invalid or incomplete identity records.

Authentication and security considerations

API-key authentication

Zip documents API-key-based authentication for programmatic access, generally using a bearer token or API key in the HTTP authorization headers. Confirm the exact header format, permissions, and key lifecycle for the target tenant.

Credential protection

Store Zip credentials in Martini Secrets Management rather than embedding them in workflows, mappings, scripts, or source control. Use environment-specific credentials and rotate them according to organizational policy.

Least privilege

Use a dedicated integration identity with only the access required for the Zip objects and actions involved. Procurement data may be subject to approval, supplier, accounting, and organizational access controls.

OAuth considerations

OAuth 2.0 may apply to some Zip-managed application or partner authorization flows, but a general-purpose OAuth flow for all Zip API resources was not verified. Do not assume OAuth is available for direct API access.

Operational considerations for Zip integrations

Rate limits and pagination

Confirm Zip request limits, page-size constraints, cursor behavior, and ordering guarantees. Use bounded concurrency, exponential backoff for transient responses, and durable checkpoints for scheduled synchronization.

Idempotency and ordering

Use stable external identifiers for Requests, Vendors, Purchase Orders, and Invoices. Treat webhook delivery as potentially duplicated or out of order, and reconcile a timed-out create request before issuing another create operation.

Approval and schema changes

Model approval state separately from downstream processing state. Zip fields and status values can depend on tenant configuration, custom forms, accounting dimensions, approval rules, and enabled modules, so test configuration changes before production rollout.

Webhook reliability

Validate webhook authenticity using the tenant’s documented mechanism, acknowledge promptly, process asynchronously where appropriate, and retain periodic reconciliation because event coverage and delivery may be limited.

Observability

Log correlation IDs, Zip object IDs, source identifiers, endpoint names, HTTP status codes, and retry counts without exposing API keys or sensitive procurement data. Monitor both transport failures and business exceptions.

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

Reusable orchestration

Martini centralizes Zip API calls, webhook intake, scheduled polling, validation, mapping, target updates, and exception handling in maintainable workflows rather than scattering logic across scripts.

Adaptable integration logic

Zip procurement fields and approval structures can vary by tenant. Martini lets developers apply explicit mappings, transformations, and business rules while retaining the option to extend workflows with custom JVM-compatible logic when necessary.

Reliable synchronization

Checkpointing, pagination, idempotency, bounded retries, and reconciliation workflows provide stronger operational controls than a one-off point-to-point script.

Controlled APIs

Martini can expose an internal API façade that gives downstream applications a stable contract while isolating Zip-specific authentication, object models, lifecycle rules, and API changes.

Frequently asked questions

How can Zip be integrated with enterprise systems?

Zip can be integrated primarily through its REST APIs, which expose procurement objects such as Requests, Approvals, Purchase Orders, Vendors, Invoices, and Users. Zip also supports webhook-style notifications for selected events, while scheduled REST polling can cover gaps in event coverage. API-key authentication is documented for programmatic access.

Can Martini integrate with Zip?

Yes. Martini can consume Zip REST APIs, receive supported Zip webhook notifications through a Martini API, run scheduled synchronization workflows, map Zip procurement objects, apply validation and business rules, and deliver results to enterprise applications.

Do I need a connector to integrate Zip with Martini?

No. A dedicated Zip connector is not required. Martini can integrate with Zip using its confirmed REST APIs, selected webhook notifications, API-key authentication, and scheduled workflows for polling and reconciliation.

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

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

Which Zip integration methods should architects use?

Use Zip’s REST APIs as the primary mechanism. Use webhook-style notifications for lifecycle events confirmed to be available in the tenant, and scheduled, paginated REST synchronization for unsupported or reconciliation scenarios. GraphQL and SOAP were not confirmed for Zip.

Are Zip events and webhooks available for synchronization?

Zip supports webhook-style notifications for selected objects or lifecycle events, but coverage is not universal. Confirm the required events for the target tenant and retain scheduled reconciliation because some objects or delivery scenarios may require polling.

How does Martini handle Zip data mapping and synchronization?

Martini can retrieve or receive Zip payloads, map them to canonical and target models, validate procurement and organizational fields, apply approval and status rules, and persist checkpoints and cross-system identifiers. This supports incremental synchronization with overlap windows and duplicate handling.

How does Martini handle Zip errors, retries, and duplicates?

Martini can distinguish transient HTTP failures from business exceptions, apply bounded retries and backoff, and route invalid data for review. Workflows can use event identifiers or deterministic object correlations for deduplication and stable external references for idempotent updates. Martini can also expose an API façade that hides Zip-specific details from other applications.

Related Martini documentation

Zip APIs

Workflows

Data processing

Security

Operations

Connect Zip with your enterprise systems

Use Martini to build maintainable Zip integrations with REST APIs, selected webhook events, scheduled synchronization, secure credentials, and workflow-based data transformation.

EXPLORE MARTINI
BOOK A DEMO