Zip (platform)

Zip is an intake-to-procure orchestration platform — one front door for any purchase request that routes through the right approvals and into the ERP. Its REST API and low-code App Studio let partners read and write Zip's procurement objects, so VMS Agent can publish canonical intent as an intake request and track it through to purchase order.

Reference
API at a glance

The public API facts VMS Agent's adapter relies on. Tenant-specific details (custom fields, picklists, approval chains) are confirmed during connection and folded into the MappingProfile.

AuthenticationCredential-based — unique keys issued per partner for separate sandbox and production environments. Build and certify against sandbox, then enable in production. No public self-service signup.
API styleREST (JSON request/response, standard HTTP status codes). App Studio adds low-code REST/SOAP endpoint actions, triggers and branching.
Base URLProvisioned per customer (sandbox + production). No single public base URL.
ObjectsIntake / purchase request, Requisition, Vendor (supplier), Contract, Purchase Order, Invoice
Events / webhooksEvent-driven via App Studio triggers + bi-directional sync; integration status and activity logs. Push or poll depending on the configured action.
Rate limitsNot publicly documented; defined per partner integration agreement.
Readiness
Docs confidence: Customer

“Docs confidence” describes how deterministic our mapping templates can be before we connect to a tenant. Even with public docs, implementations vary — especially around custom fields, approval flows and object extensions.

Deterministic mapping

Common Workforce Model fields map to known API fields. Best for standard objects (requisitions, assignments, timesheets, POs).

Tenant discovery

VMS Agent can scan tenant configuration (custom fields, picklists, required fields) where the platform permits it, then generate a tenant‑specific MappingProfile.

Enrichment loop

If the target platform requires a field the Intent record doesn't yet have, VMS Agent emits an enrichment_request back to the intake layer.

Mapping
Minimum viable mapping for Zip

An opinionated baseline. The platform adapter enforces additional requirements via preflight. “Tenant required” fields are discovered during connection and added to the MappingProfile.

Object Canonical fields Platform target Required status Notes
Intake request
The single front door
role_title, service_category, cost_center, dates, amount Intake / Purchase Request (App Studio action) Required Zip routes it through the right approvals
Vendor
Resolve / onboard supplier
supplier_name, tax_id, contact Vendor object Tenant required Vendor onboarding gates the PO
Purchase Order
Transact + back-sync
po_lines, supplier, amount, status Purchase Order object Read Read for reconciliation / liveness
Idempotency & drift — publish + reconcileExpand

Publish operations are idempotent using a deterministic key {intent_id}-{intent_version}-{target_system}. Because humans can change records inside the platform, VMS Agent supports reconciliation: it compares the platform record snapshot to the canonical intent and flags drift.

Tenant specifics
Custom fields & unique mapping

Real deployments rely on program-specific custom fields (for compliance, approvals, GL coding, rate rules or supplier constraints). VMS Agent is designed to generate tenant‑specific mappings rather than forcing you to redesign your intake.

How scanning works

High-level flow

connect_destination() → read required fields + picklists (where permitted) → detect custom fields / extensions → build MappingProfile + validation rules → preflight intent against tenant requirements

What gets produced

Portable artefacts

MappingProfile (tenant-scoped) Capabilities matrix Required-field rules Picklist dictionaries Enrichment prompts Audit spine links (defence_file_ref)
Important — where this platform is tenant-definedExpand

Zip is configuration-heavy: intake forms, approval chains, custom fields and routing logic are tenant-defined in the workflow builder, and App Studio is the supported low-code path for custom triggers and actions. The API surface is partner-gated — endpoints, credentials and base URLs are provisioned by Zip during onboarding. Note: ziphq.com (now zip.com) is the procurement platform, which is unrelated to the Zip Co buy-now-pay-later product at zip.co.

Next
Implement the adapter

Use this page alongside the API + Schemas docs to implement: destination connection, preflight validation, publish, webhook back-sync and reconciliation.