Ellipse Gradient for Header

Procurify Integration Guide

Connect Procurify procurement and spend-management data with enterprise systems through REST APIs, OAuth 2.0 authorization, scheduled workflows, and controlled event-driven patterns.

Procurify integration options at a glance

Procurify’s primary documented integration mechanism is its REST API platform, with access, resource coverage, permissions, and API version determined by the Procurify account and current developer documentation. Martini can authenticate with Procurify using OAuth 2.0-style credentials, retrieve JSON resources, apply validation and business rules, and synchronize approved procurement data through scheduled workflows. Common designs cover Users, Vendors, Purchase Requests, Purchase Orders, Bills, and Budgets. Webhook-style notifications may be available for selected events, but broad webhook coverage is not confirmed. No Procurify bulk API, direct database access, or general attachment API has been verified, so larger transfers should use paginated, incremental REST requests with checkpoints and idempotent upserts.

Integration pointSupported by Procurify?Common use casesHow Martini supports it
REST APIsYesRetrieve and, where resource permissions allow, create or update Users, Vendors, Purchase Requests, Purchase Orders, Bills, and Budgets. REST APIs are the primary documented Procurify integration mechanism.Martini can consume Procurify REST endpoints, parse JSON responses, transform payloads, apply business rules, and expose separate APIs for downstream applications.
AuthenticationYesProcurify API access is associated with OAuth 2.0-style authorization, including application registration, credentials, scopes, and access-token handling.Martini can store client credentials and tokens in Secrets Management, send bearer tokens, and orchestrate token refresh behavior where Procurify’s grant and refresh model supports it.
Webhooks / outbound callbacksNot confirmedWebhook-style notifications may be available for selected Procurify events, but universal coverage across procurement objects has not been verified.If enabled for the Procurify account, Martini can expose an API endpoint to receive notifications and trigger a workflow; otherwise scheduled REST polling is the safer design.
Pagination and incremental REST synchronizationYesRecurring synchronization can retrieve changed procurement data through paginated requests and documented filters, subject to the current Procurify API reference.Martini can schedule workflows, persist checkpoints, process pages, use overlap windows where appropriate, and perform idempotent target upserts.
Bulk / asynchronous APIsNot confirmedNo official Procurify bulk or asynchronous API was verified. Large transfers should be designed around pagination and scheduled incremental pulls.Martini can control request concurrency, checkpoint progress, throttle calls, and retry transient failures without assuming a bulk endpoint.
File / attachment APIsNot confirmedBills, Purchase Orders, or receipts may contain documents, but a general Procurify attachment API has not been verified.Martini can handle files when Procurify documents an accessible file or attachment endpoint, but the resource, permissions, content format, and size limits must first be confirmed.
Database / analytics accessNoNo direct Procurify database or analytics access mechanism was confirmed. Procurify should be integrated as an application service through supported APIs or exports.Martini can connect to downstream databases when required, but it should not rely on direct Procurify database connectivity.
JSON payloadsYesProcurify REST integrations use JSON-style resource payloads for procurement and spend-management data, subject to the current API reference.Martini can parse, validate, map, transform, and route Procurify JSON within workflows and APIs.

How Procurify exposes data and business events

Procurify REST APIs

Procurify’s primary documented integration mechanism is its REST API platform. The available resources, operations, API version, permissions, pagination behavior, and account access requirements must be confirmed in the current Procurify developer documentation. Candidate resources include Users, Vendors, Purchase Requests, Purchase Orders, Bills, and Budgets.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with Procurify, calls the required REST endpoint, retrieves paginated JSON data, validates lifecycle and reference fields, maps the payload to a canonical model, and writes it to the target system. For write-back, each resource’s create or update permissions must be verified separately.

Implementation sequence

Authenticate with Procurify using the configured OAuth 2.0 credentials
Retrieve the required resource page from the Procurify REST API
Apply pagination, filtering, and checkpoint rules
Validate approval status, identifiers, and accounting references
Map Procurify JSON to the target-system model
Upsert the target object using the Procurify identifier as an external key

Scheduled incremental synchronization

No verified bulk or asynchronous Procurify API was identified, so scheduled incremental REST synchronization is the conservative approach for recurring transfers. The workflow should use documented filtering and pagination behavior where available.

Martini implementation pattern

Martini implementation pattern: a scheduler starts the workflow, the workflow reads the stored checkpoint, retrieves changed Procurify resources in pages, processes each object idempotently, and persists a new checkpoint only after successful handling. Rate limits and overlap windows should be accounted for in the design.

Implementation sequence

Start the workflow on a defined schedule
Read the last successful synchronization checkpoint
Retrieve changed Procurify objects in paginated requests
Transform and upsert each object in the target system
Record failures without advancing the affected checkpoint
Persist the new high-water mark after reconciliation

Procurify event notifications

Webhook or outbound-callback support is not confirmed for all Procurify object types. If the current Procurify account exposes selected event notifications, those events can provide a lower-latency trigger than scheduled polling.

Martini implementation pattern

Martini implementation pattern: Martini exposes a controlled API endpoint, receives a Procurify notification when the account and event type support it, validates the request, retrieves the current Procurify resource rather than relying only on the event payload, and invokes the same mapping and idempotency workflow used by scheduled synchronization.

Implementation sequence

Expose a secured Martini API endpoint for the confirmed event type
Receive and validate the Procurify notification
Retrieve the current Procurify resource
Apply lifecycle and business-rule checks
Map and upsert the target object
Log the outcome and retry recoverable failures

Procurify OAuth 2.0 authorization

Procurify API integrations are associated with OAuth 2.0-style authorization. Exact grants, scopes, token endpoints, refresh behavior, and administrator approval requirements must be confirmed in the current developer portal.

Martini implementation pattern

Martini implementation pattern: credentials and tokens are kept in Secrets Management, API requests use bearer access tokens, and the workflow handles expiry or refresh according to the Procurify authorization model. Scopes should be limited to the resources and operations required by the integration.

Implementation sequence

Register or obtain the Procurify application credentials
Configure the confirmed OAuth grant and scopes
Store client secrets and refresh credentials securely
Request or refresh the access token
Send the bearer token with Procurify API requests
Route authorization failures for operational remediation

Common Procurify integration patterns

Pattern 1: Synchronize approved Purchase Orders to an ERP

When to use this pattern

Use this pattern when procurement approvals must result in ERP purchasing commitments. A scheduled workflow retrieves approved or changed Purchase Orders, resolves Vendors and accounting dimensions, and prevents incomplete or duplicate postings.

Integration direction
Procurify
Martini
NetSuite
Example Mapping
Procurify FieldCanonical FieldTarget Field
Purchase Order IDsourceDocumentIdexternalId
Vendor IDsupplierIdvendorId
Total amountdocumentTotaltotal
Approval statuslifecycleStatusapprovalStatus
Martini implementation pattern

Martini retrieves pages of eligible Purchase Orders, validates approval status and Vendor references, enriches each order with mapped accounting dimensions, and upserts it into the ERP. Stable source IDs and stored target IDs prevent duplicates, while rate-limit responses and transient failures are retried without losing the synchronization checkpoint.

Martini capabilities used
  • workflows
  • scheduler triggers
  • API consumption
  • data mapping
  • business rules
  • idempotent upserts
  • error handling

Pattern 2: Send Bills to an accounts-payable platform

When to use this pattern

Use this pattern when Procurify Bills need to be posted to accounting systems such as QuickBooks Online, Xero, or Sage Intacct. The workflow should only process eligible lifecycle states and should reconcile invoice identity before posting.

Integration direction
Procurify
Martini
Sage Intacct
Example Mapping
Procurify FieldCanonical FieldTarget Field
Bill IDsourceBillIdexternalId
Invoice numberinvoiceNumberinvoiceNumber
Vendor IDsupplierIdvendorId
CurrencycurrencyCodecurrency
Martini implementation pattern

A scheduled Martini workflow retrieves incremental Bills, validates invoice number, status, currency, tax, and Vendor references, then maps the payload to the accounts-payable model. It looks up the external key before creating a Bill, updates only changed source data, and sends validation or reconciliation failures to an operational queue or retry process.

Martini capabilities used
  • workflows
  • JSON handling
  • data mapping
  • validation
  • business rules
  • API consumption
  • retry and reconciliation

Pattern 3: Synchronize supplier master data

When to use this pattern

Use this pattern when an ERP or accounting system is the authoritative source for supplier data and Procurify requires aligned Vendors. Write support must be confirmed for the Procurify Vendor resource and the assigned OAuth scopes.

Integration direction
NetSuite
Martini
Procurify
Example Mapping
Procurify FieldCanonical FieldTarget Field
Vendor external IDsupplierIdexternalId
Legal namesupplierLegalNamename
Tax identifiertaxIdtaxId
Payment termspaymentTermspaymentTerms
Martini implementation pattern

Martini retrieves approved supplier changes from the source system, applies controlled matching using stable IDs and validated legal attributes, and calls Procurify write operations only where documented. Inactive supplier handling, permission failures, and ambiguous matches are routed for review rather than automatically merged.

Martini capabilities used
  • API consumption
  • workflows
  • data mapping
  • matching rules
  • validation
  • conditional routing
  • error handling

Pattern 4: Synchronize users and organizational data

When to use this pattern

Use this pattern when worker, manager, department, or location changes in Workday or Microsoft Entra ID must align with Procurify approval structures. The required Procurify resources and write permissions should be verified before implementation.

Integration direction
Workday
Martini
Procurify
Example Mapping
Procurify FieldCanonical FieldTarget Field
Worker IDuserIdUser identifier
Worker statusactiveStatusStatus
Manager IDmanagerIdManager
DepartmentdepartmentCodeDepartment
Martini implementation pattern

Martini retrieves approved organizational changes, maps users and organizational attributes, validates manager and department references, and applies activation or deactivation rules. The workflow records source and target identifiers, avoids destructive updates where mappings are incomplete, and reports rejected changes for reconciliation.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • validation
  • business rules
  • secrets management
  • monitoring

Applications commonly integrated with Procurify

Procurify can be integrated with finance, ERP, HR, identity, and collaboration applications when the required Procurify resources, permissions, and target-system interfaces are available. The relationships below are enterprise architecture patterns; Procurify-native support and object coverage should be validated for each implementation.

Application Scenario Direction Martini Pattern
NetSuite Transfer Vendors, Purchase Orders, Bills, and accounting dimensions between procurement and ERP processes. Procurify → Martini → NetSuite A scheduled Martini workflow retrieves approved Procurify Purchase Orders and Bills, resolves Vendors and accounting dimensions, maps them to NetSuite payloads, and performs idempotent upserts with reconciliation handling.
QuickBooks Online Send approved purchasing and bill information to accounting while reducing manual re-entry. Procurify → Martini → QuickBooks Online Martini retrieves incremental Bills and related procurement data from Procurify, validates invoice numbers and status, transforms the payload, and submits it to QuickBooks Online with duplicate detection and retry handling.
Xero Synchronize supplier and payable information between Procurify and cloud accounting workflows. Procurify → Martini → Xero A Martini workflow maps Procurify Vendors and Bills into Xero-compatible structures, applies currency and tax rules, and stores source-to-target identifiers for safe reruns.
Sage Intacct Post procurement and accounts-payable information while preserving departments, locations, and other accounting dimensions. Procurify → Martini → Sage Intacct Martini retrieves approved Procurify transactions, validates dimension mappings, transforms JSON into the Sage Intacct request model, and routes rejected or unmatched transactions to reconciliation.
Microsoft Dynamics 365 Align procurement transactions, suppliers, and accounting data with an ERP environment. Procurify → Martini → Microsoft Dynamics 365 Martini orchestrates incremental Procurify reads, matches Vendors and Purchase Orders to Dynamics 365 identifiers, applies approval and lifecycle rules, and updates the ERP with controlled retries.
Workday Synchronize worker, manager, department, or organizational information used in purchasing approvals. Workday → Martini → Procurify Martini consumes approved Workday organizational data, maps active users and departments to Procurify resources where supported, and applies activation, manager, and least-privilege rules.
Microsoft Entra ID Support user lifecycle and identity alignment for Procurify users. Microsoft Entra ID → Martini → Procurify A Martini workflow receives or retrieves approved identity data, maps user status and organizational attributes to Procurify Users where the API permits, and records provisioning outcomes.
Slack Notify procurement teams about approval, purchasing, or exception events. Procurify → Martini → Slack If Procurify provides the required event notification, Martini receives it through an API endpoint, retrieves current resource details, evaluates business rules, and sends a formatted Slack notification; otherwise a scheduled polling workflow can be used.

How to build a Procurify integration in Martini

Objective

Establish Procurify access using the account’s documented OAuth 2.0 configuration and limit permissions to the resources and operations required by the integration.

Instructions in Martini

  • Confirm the Procurify API version, resource access, OAuth grant, scopes, and administrator approvals.
  • Store client credentials, access tokens, and refresh credentials in Martini Secrets Management.
  • Configure bearer-token requests and token-expiry or refresh handling.

Objective

Select a schedule for dependable synchronization or use a Procurify event notification only when the account and required event type are confirmed.

Instructions in Martini

  • Use a scheduler for recurring incremental REST synchronization.
  • If supported, expose a secured Martini API endpoint for selected Procurify notifications.
  • Define overlap windows, checkpoints, and retry behavior before processing data.

Objective

Read Procurify resources through paginated REST requests and preserve enough source metadata to support incremental processing and reconciliation.

Instructions in Martini

  • Retrieve Users, Vendors, Purchase Requests, Purchase Orders, Bills, or Budgets as required.
  • Implement documented pagination, filtering, and sorting behavior.
  • Track source identifiers, update timestamps, processing status, and synchronization checkpoints.

Objective

Coordinate API calls, reference resolution, validation, transformation, target writes, and failure routing as a maintainable Martini workflow.

Instructions in Martini

  • Resolve related Vendors, users, departments, locations, or accounting dimensions where required.
  • Separate retrieval, transformation, target write, and reconciliation stages.
  • Route recoverable failures to bounded retries and non-recoverable failures to operational review.

Objective

Convert Procurify JSON payloads into a canonical model and then into the target application’s schema without coupling every target directly to vendor fields.

Instructions in Martini

  • Map stable Procurify IDs to external keys.
  • Normalize statuses, amounts, currencies, dates, tax fields, and accounting dimensions.
  • Use validation rules for missing references, invalid lifecycle states, and ambiguous vendor matches.

Objective

Ensure only eligible procurement data is posted or propagated according to approval, lifecycle, permission, and duplicate-prevention requirements.

Instructions in Martini

  • Distinguish draft, pending, approved, rejected, canceled, closed, and amended objects where available.
  • Do not post every returned object automatically to an ERP or accounting platform.
  • Use idempotency checks before creating Purchase Orders, Bills, Vendors, or other target objects.

Common Procurify data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
UsersSynchronize employees and other Procurify users involved in procurement and approvals.Workday, Microsoft Entra ID, enterprise identity directories, ERP systemsMartini maps stable identifiers, activation status, managers, departments, and other confirmed fields, then applies least-privilege and duplicate-prevention rules.
VendorsMaintain supplier records used on purchase requests, Purchase Orders, Bills, and other spend transactions.NetSuite, Sage Intacct, QuickBooks Online, Xero, Microsoft Dynamics 365Martini matches by source identifiers where possible, validates legal names and tax or payment attributes, and performs controlled upserts.
Purchase RequestsRepresent employee requests for goods or services and their approval lifecycle.ERP systems, approval reporting platforms, data warehousesMartini retrieves eligible requests, evaluates status and approval rules, maps accounting dimensions, and routes invalid or incomplete requests for reconciliation.
Purchase OrdersRepresent approved purchasing commitments issued to Vendors.NetSuite, Sage Intacct, Microsoft Dynamics 365, accounting platformsMartini processes approved or changed Purchase Orders, resolves Vendor and accounting references, stores target IDs, and prevents duplicate creation during retries.
BillsRepresent supplier invoices or payable documents associated with procurement activity.QuickBooks Online, Xero, Sage Intacct, NetSuite, Microsoft Dynamics 365Martini validates status, invoice numbers, currency, tax treatment, and references before transforming and posting Bills with idempotency controls.
BudgetsRepresent budget structures used to control and report organizational spending.ERP systems, finance reporting platforms, data warehousesMartini maps budget identifiers, periods, departments, and dimensions where exposed, then synchronizes approved data with checkpointing and validation.

Authentication and security considerations

OAuth 2.0-style authorization

Procurify API access is associated with OAuth 2.0-style authorization. The current developer documentation should be used to confirm the grant type, token endpoint, scopes, refresh-token behavior, and administrator approval requirements.

Credential protection

Store Procurify client credentials, access tokens, and refresh credentials in Martini Secrets Management rather than embedding them in workflows or mappings. Request only the scopes required for the integration.

Least privilege

  • Separate read-only synchronization credentials from credentials that can create or update Procurify objects.
  • Confirm whether access is controlled by Procurify roles, organization permissions, API scopes, or a combination of these.
  • Protect any Martini API endpoint used for event notifications with appropriate authentication and authorization.

Operational considerations for Procurify integrations

Pagination and rate limits

Confirm Procurify page size, cursor or offset behavior, filtering, sorting, and tenant-specific rate limits. Martini workflows should throttle requests, avoid uncontrolled parallelism, handle 429 responses, and use bounded exponential backoff.

Incremental processing

Persist checkpoints based on documented timestamps or identifiers where available. Use overlap windows when timestamp precision or ordering is uncertain, and reconcile totals or high-water marks after each run.

Lifecycle and idempotency

Do not treat every returned object as ready for ERP or accounting posting. Distinguish draft, pending, approved, rejected, canceled, closed, and amended states, and use stable Procurify IDs plus target IDs to prevent duplicates.

Schema and testing

Monitor the Procurify developer documentation for API-version changes, deprecated fields, new required properties, and enum changes. Test pagination, token expiry, rate limits, partial failures, reference mismatches, and replayed events before production deployment.

Attachments and reconciliation

Confirm attachment resources, permissions, binary or signed-URL behavior, and size limits before implementing document transfer. Route failed objects to operational retry or reconciliation processes instead of silently skipping them.

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

Centralized orchestration

Martini provides a maintainable workflow for authentication, Procurify API calls, pagination, reference resolution, business rules, target writes, and reconciliation rather than scattering logic across scripts or point-to-point jobs.

Reusable transformations

Mappings can separate Procurify-specific JSON handling from canonical and target-system models. This makes it easier to support multiple ERP or accounting destinations while preserving consistent Vendor, Purchase Order, Bill, and accounting rules.

Operational reliability

Martini workflows can implement checkpoints, idempotent upserts, rate-limit handling, retries, validation, logging, and controlled failure routing. These controls are important when procurement objects change lifecycle state or when a synchronization run is interrupted.

API-led integration

Martini can consume Procurify APIs and expose controlled APIs for downstream applications or potential Procurify event callbacks. This provides a governed integration boundary without requiring a dedicated vendor connector.

Frequently asked questions

How can Procurify be integrated with enterprise systems?

Procurify’s primary documented integration method is its REST API platform, accessed according to the account’s available resources, permissions, and API version. Enterprise systems can synchronize Users, Vendors, Purchase Requests, Purchase Orders, Bills, and Budgets through authenticated, paginated, scheduled API workflows. Webhook-style notifications may be available for selected events, but broad event coverage is not confirmed.

Can Martini integrate with Procurify?

Yes. Martini can integrate with Procurify by consuming its REST APIs, using OAuth 2.0-style authentication, transforming JSON payloads, orchestrating scheduled workflows, and exposing an API endpoint if supported Procurify event notifications are required. Resource-level read and write permissions should be confirmed for each use case.

Do I need a connector to integrate Procurify with Martini?

No. A dedicated Procurify connector is not required. Martini can use Procurify’s confirmed native integration mechanisms, primarily its REST APIs and OAuth 2.0-style authorization, with scheduled synchronization and potentially selected event notifications where the Procurify account supports them.

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

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

Which Procurify integration methods should be used?

Use Procurify’s REST APIs as the primary method for current integrations. OAuth 2.0-style authorization should be configured according to the Procurify developer platform. Scheduled, paginated, incremental workflows are the conservative approach because bulk, asynchronous, GraphQL, SOAP, and direct database access were not confirmed.

Does Procurify support webhooks or event notifications?

Webhook or outbound-callback support was not verified for all Procurify objects. If the current Procurify account supports selected event types, Martini can receive notifications through a secured API endpoint and retrieve the current resource before processing it. Otherwise, scheduled REST polling should be used.

How does synchronization and data mapping work?

Martini can retrieve Procurify resources in pages, apply incremental filters and checkpoints where supported, map JSON into a canonical model, and upsert target records using stable Procurify identifiers. Workflows can apply approval, Vendor, accounting, currency, tax, and lifecycle rules before writing to ERP or accounting systems.

How are Procurify errors, retries, and duplicates handled?

A robust Martini workflow distinguishes authentication failures, authorization errors, validation failures, rate limits, missing references, and transient server errors. It can apply bounded retries and backoff, persist checkpoints, and use Procurify object IDs with target-system IDs to prevent duplicate Purchase Orders, Bills, Vendors, or other objects. Martini can also expose an API façade for downstream applications while centralizing these controls.

Related Martini documentation

APIs

Workflows

Data

Security

Operations

Connect Procurify with your enterprise systems

Use Martini to build secure, maintainable Procurify integrations for procurement synchronization, ERP and accounting workflows, organizational data, and API-led automation.

EXPLORE MARTINI
BOOK A DEMO