Ellipse Gradient for Header

BILL Integration Guide

BILL integrates with enterprise systems through OAuth-authenticated REST APIs, selected webhook notifications, and document-related API operations.

BILL integration options at a glance

BILL’s primary integration model is its HTTP REST API, which supports access to business objects such as Vendors, Customers, Bills, Invoices, Payments, and Purchase Orders. BILL also provides webhook-style notifications for selected resources and events, although coverage must be confirmed for each use case. Document and attachment operations may be available for accounts-payable workflows, subject to endpoint, permission, and file-format requirements. OAuth 2.0 secures application access. Martini can consume BILL APIs, receive supported notifications, orchestrate scheduled or event-driven workflows, paginate through resources, map JSON payloads, and expose normalized APIs to internal applications.

Integration pointSupported by BILL?Common use casesHow Martini supports it
REST APIsYesBILL’s principal integration mechanism for reading and synchronizing Vendors, Customers, Bills, Invoices, Payments, and Purchase Orders; creating or updating financial objects where the account and API permissions allow.Martini can consume BILL REST endpoints from workflows, transform JSON payloads, apply business rules, and expose normalized APIs for internal applications.
Webhooks / outbound callbacksLimitedBILL provides webhook-style notifications for selected resource changes and business events. Coverage, payload detail, authenticity validation, and delivery behavior must be confirmed for the required product and event.Martini can expose an API or use a webhook-consuming workflow to receive notifications, validate them, retrieve the authoritative BILL object, and route the result.
File / attachment APIsLimitedBILL accounts-payable workflows support document or attachment-related use cases, such as bill documentation. Upload, download, encoding, file size, and permission requirements vary by endpoint.Martini can orchestrate attachment retrieval and transfer to another API or file-processing workflow when BILL exposes the required operation.
Incremental synchronizationYesSynchronize changed Bills, Invoices, Vendors, Customers, or Payments using timestamps, status filters, pagination, and persisted watermarks where those fields are available.Martini scheduled workflows can process pages incrementally, persist cursors or watermarks, and use stable BILL identifiers for upsert and deduplication.
Bulk / asynchronous / batch APIsNot confirmedNo broad vendor-wide bulk or asynchronous API capability was confirmed. Resource-specific behavior should be checked in the current BILL API documentation.Martini can still implement controlled batching over paginated REST responses, with checkpoints, throttling, and retry handling.
AuthenticationYesBILL application integrations use OAuth 2.0 with application credentials, access tokens, refresh handling, environment-specific credentials, and account or scope permissions.Martini can store credentials and tokens in secure environment configuration and secrets, then manage authenticated API requests within workflows.
Database accessNoNo customer-facing direct database interface was confirmed for BILL. Integrations should use documented APIs and supported notifications or exports.Martini can connect to a customer-managed database for integration state, reconciliation, or downstream storage, but not to BILL’s underlying database.

How BILL exposes data and business events

BILL REST APIs

BILL’s primary developer integration model is an HTTP REST API for business objects and transactions. The available endpoints and operations depend on the current API version, product configuration, account permissions, and resource.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with OAuth 2.0, calls the required BILL endpoint, handles pagination and response status, maps the returned JSON, applies financial business rules, and writes the result to a target API, database, file, or internal Martini API.

Implementation sequence

Authenticate with BILL using the configured OAuth application
Call the required BILL REST endpoint
Process paginated responses without loading the full history
Validate and transform the BILL JSON payload
Write the result to the target system
Persist identifiers and synchronization state

BILL Webhook Notifications

BILL supports webhook-style notifications for selected resource changes and business events. Notifications should not be assumed to cover every object or lifecycle transition, and the event payload may contain only an identifier.

Martini implementation pattern

Martini implementation pattern: expose a controlled endpoint or webhook-consuming workflow, validate authenticity and event structure, acknowledge or queue the notification as appropriate, retrieve the current BILL object, and route the normalized event to downstream systems with duplicate and out-of-order handling.

Implementation sequence

Receive the BILL webhook notification
Validate authenticity and required event fields
Check the event identifier and deduplication state
Retrieve the current BILL resource when the payload is incomplete
Map the resource to the downstream event model
Route the event and record processing status

BILL Attachments

BILL supports document-related use cases in accounts-payable workflows, but attachment operations, formats, request encoding, size limits, and permissions must be confirmed for the selected endpoint and resource.

Martini implementation pattern

Martini implementation pattern: retrieve attachment metadata or content through the BILL API, authenticate any protected download, transform or stream the file as required, and transfer it to a target endpoint or file-processing workflow while preserving the parent Bill or Invoice reference.

Implementation sequence

Identify the parent BILL object and attachment
Confirm attachment permissions and supported operation
Retrieve metadata or binary content from BILL
Validate file type and size
Transfer the attachment to the target system
Record the source identifier and transfer outcome

BILL Scheduled Synchronization

Scheduled synchronization is suitable for resources without the required event coverage and for reconciliation of BILL data. Timestamps, status filters, pagination, and watermarks should be used only where supported by the resource.

Martini implementation pattern

Martini implementation pattern: a scheduler starts a workflow that reads changed BILL objects in controlled pages, transforms and validates them, writes them to the target, and persists a checkpoint only after successful processing.

Implementation sequence

Start the scheduled synchronization workflow
Load the last successful watermark or cursor
Retrieve the next page of changed BILL objects
Transform and validate each object
Upsert the target record using stable identifiers
Persist the checkpoint after successful writes

Common BILL integration patterns

Pattern 1: Synchronize Bills with an ERP

When to use this pattern

Use this pattern when approved supplier and payable information must move between BILL and an ERP such as NetSuite, Sage Intacct, or Microsoft Dynamics 365 Business Central. The workflow should distinguish approved, rejected, paid, and cancelled states and avoid duplicate financial documents.

Integration direction
BILL
Martini
NetSuite
Example Mapping
BILL FieldCanonical FieldTarget Field
BILL vendorIdsupplier.idNetSuite vendor.internalId
BILL billNumberpayable.documentNumberNetSuite vendorBill.tranId
BILL amountpayable.totalAmountNetSuite vendorBill.total
BILL statuspayable.lifecycleStatusNetSuite vendorBill.status
Martini implementation pattern

A scheduled or event-driven Martini workflow retrieves or receives the BILL Bill, loads related Vendor data when needed, validates supplier and monetary fields, maps the document into the ERP model, and upserts it using a durable source reference. Transient failures are retried with backoff, while validation failures and uncertain create responses are sent to reconciliation handling.

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

Pattern 2: Synchronize BILL Payments to accounting systems

When to use this pattern

Use this pattern when an accounting ledger or reporting database needs current payment status for Bills, Invoices, or Customers. It is appropriate for periodic status synchronization and reconciliation when event coverage is incomplete.

Integration direction
BILL
Martini
QuickBooks Online
Example Mapping
BILL FieldCanonical FieldTarget Field
BILL paymentIdpayment.idQuickBooks Online Payment.Id
BILL paymentStatuspayment.statusQuickBooks Online Payment.TxnStatus
BILL paymentAmountpayment.amountQuickBooks Online Payment.TotalAmt
BILL paymentDatepayment.effectiveDateQuickBooks Online Payment.TxnDate
Martini implementation pattern

Martini loads the last watermark, retrieves changed Payments and related Bills through paginated BILL API calls, maps status values explicitly, and updates the target ledger. The workflow stores BILL identifiers and response state, throttles requests, and retries transient failures without creating duplicate payment records.

Martini capabilities used
  • workflows
  • API consumption
  • pagination orchestration
  • data mapping
  • state management
  • retry handling

Pattern 3: Process BILL event notifications

When to use this pattern

Use this pattern when selected BILL approval, payment, creation, update, or status events need to trigger downstream processing. The exact event must be confirmed because BILL webhook coverage is selective.

Integration direction
BILL
Martini
Slack
Example Mapping
BILL FieldCanonical FieldTarget Field
BILL eventTypebusinessEvent.typeSlack message.title
BILL resourceIdbusinessEvent.resourceIdSlack message.context
BILL statusbusinessEvent.statusSlack message.body
BILL updatedAtbusinessEvent.occurredAtSlack message.timestamp
Martini implementation pattern

Martini receives the notification through an API or webhook-consuming workflow, validates authenticity, checks duplicate state, and retrieves the authoritative BILL resource when the event body is incomplete. It then applies routing rules, sends a normalized notification or downstream request, and records failures for retry or dead-letter processing.

Martini capabilities used
  • API exposure
  • webhook consumption
  • workflows
  • business rules
  • data mapping
  • error handling

Pattern 4: Synchronize BILL Customers and Invoices

When to use this pattern

Use this pattern when a CRM, customer portal, or finance application needs aligned customer and receivables information from BILL. The workflow should normalize tax details, invoice lines, dates, totals, and lifecycle statuses before writing the destination.

Integration direction
BILL
Martini
Salesforce
Example Mapping
BILL FieldCanonical FieldTarget Field
BILL customerIdcustomer.externalIdSalesforce Account.BILL_Id__c
BILL customerNamecustomer.nameSalesforce Account.Name
BILL invoiceNumberinvoice.numberSalesforce Invoice__c.Invoice_Number__c
BILL dueDateinvoice.dueDateSalesforce Invoice__c.Due_Date__c
Martini implementation pattern

A Martini workflow retrieves changed Customers and Invoices, enriches invoice data with related customer references where necessary, converts decimal-safe amounts and normalized dates, and upserts Salesforce objects. It stores cross-system IDs, rejects incomplete financial data before submission, and retries only safe operations.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • transformation
  • validation
  • error handling

Applications commonly integrated with BILL

BILL can be integrated with accounting, ERP, customer, workforce, and collaboration applications through API-based workflows. The exact objects, operations, and directions depend on the BILL product configuration, API version, account permissions, and target application.

Application Scenario Direction Martini Pattern
QuickBooks Online Synchronize Vendors, Bills, Invoices, Payments, and accounting status between BILL and the accounting ledger. BILL → Martini → QuickBooks Online Use scheduled REST API workflows to retrieve changed BILL objects, map them to QuickBooks Online models, upsert using stable identifiers, and reconcile payment or status differences with controlled retries.
NetSuite Transfer supplier, bill, payment, purchase-order, and approval-related data between BILL and an enterprise ERP. BILL → Martini → NetSuite Orchestrate incremental BILL reads and NetSuite API writes, preserve cross-system identifiers, apply financial validation rules, and route rejected or ambiguous transactions for reconciliation.
Xero Keep suppliers, bills, invoices, and payment status aligned with the accounting platform. BILL → Martini → Xero Run a scheduled synchronization workflow using BILL timestamps, pagination, and status filters where available; transform monetary values and dates before writing Xero objects.
Sage Intacct Synchronize payable transactions, vendors, dimensions, and payment information with the general ledger. BILL → Martini → Sage Intacct Map BILL financial objects into Sage Intacct structures, validate dimensions and amounts, persist source identifiers, and use workflow error handling for failed or partial writes.
Microsoft Dynamics 365 Business Central Exchange vendor, purchase invoice, payment, and accounting data with an ERP platform. BILL → Martini → Microsoft Dynamics 365 Business Central Consume BILL REST resources, normalize supplier and invoice data, apply business rules for posting eligibility, and call Business Central APIs through reusable Martini workflows.
Salesforce Coordinate customer, account, invoice, and payment information with sales and customer-service processes. Salesforce → Martini → BILL Receive Salesforce changes or poll approved source data, transform customer and invoice models into BILL payloads, and return BILL identifiers and status updates through an API or workflow.
Workday Align supplier and finance-process data with BILL accounts-payable workflows. Workday → Martini → BILL Use Martini to transform Workday supplier or finance data into BILL API requests, validate permissions and required fields, and maintain an auditable cross-reference between systems.
Slack Notify finance and approval teams about bill approvals, exceptions, or payment events. BILL → Martini → Slack Receive a supported BILL event or poll for status changes, apply routing and notification rules, and publish a concise Slack message while recording delivery and retry state.

How to build a BILL integration in Martini

Objective

Establish the BILL application connection using OAuth 2.0 and environment-specific credentials, while keeping tokens, client secrets, and scopes outside workflow source.

Instructions in Martini

  • Configure BILL OAuth application values for the target environment
  • Store client credentials and token settings in Martini secrets or secure environment configuration
  • Confirm scopes, account permissions, sandbox settings, and token refresh behavior
  • Create a reusable authenticated API configuration

Objective

Select a trigger based on BILL event coverage and synchronization requirements rather than assuming every resource provides webhook notifications.

Instructions in Martini

  • Use a BILL webhook notification for a confirmed event
  • Use a scheduler for polling, incremental synchronization, or reconciliation
  • Use an exposed Martini API when another application initiates the process
  • Define the required resource, event, and synchronization window

Objective

Receive or retrieve the authoritative BILL resource and related objects needed for processing, including follow-up API calls when a notification contains only an identifier.

Instructions in Martini

  • Receive the webhook request or start the scheduled API read
  • Retrieve the current Vendor, Customer, Bill, Invoice, Payment, or Purchase Order
  • Process paginated results incrementally
  • Persist a cursor, watermark, or event identifier after successful processing

Objective

Coordinate BILL requests, enrichment calls, target writes, and state management in a maintainable Martini workflow.

Instructions in Martini

  • Sequence resource retrieval and related-object lookups
  • Apply conditional routing for approval, payment, and exception statuses
  • Separate reusable authentication, mapping, and reconciliation logic
  • Control concurrency and request volume according to BILL limits

Objective

Convert BILL JSON and financial values into the target application’s model without losing source identifiers or important status information.

Instructions in Martini

  • Map BILL object fields to a canonical or target model
  • Normalize dates, time zones, currency codes, and decimal amounts
  • Transform invoice lines, supplier references, and lifecycle statuses
  • Retain BILL IDs, source references, and relevant timestamps

Objective

Validate financial and operational conditions before creating or updating downstream objects.

Instructions in Martini

  • Check required supplier, customer, amount, date, and status fields
  • Prevent duplicate Bills, Invoices, or Payments using durable identifiers
  • Route approval, cancellation, and settlement statuses explicitly
  • Reject or quarantine ambiguous requests for reconciliation

Common BILL data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
VendorsRepresent suppliers receiving payments through BILL and support supplier synchronization and accounts-payable processing.QuickBooks Online, NetSuite, Xero, Sage Intacct, Workday, Microsoft Dynamics 365 Business CentralMartini retrieves or receives Vendor data, validates required supplier fields, maps identifiers and financial attributes, and upserts the target representation while preserving the BILL ID.
CustomersRepresent customers associated with receivables and invoicing processes.Salesforce, QuickBooks Online, Xero, NetSuite, customer portalsMartini maps customer identifiers, tax details, contact information, and status values into the target model, applying deduplication and business rules before writing.
BillsRepresent accounts-payable obligations entered into BILL, including payable status and related supplier information.NetSuite, QuickBooks Online, Sage Intacct, Microsoft Dynamics 365 Business Central, reporting databasesMartini validates amounts, dates, supplier references, and lifecycle status; it can create or update target payables and use durable cross-references to prevent duplicates.
InvoicesRepresent accounts-receivable invoices issued to Customers, including dates, totals, lines, and status.Salesforce, QuickBooks Online, Xero, NetSuite, customer portalsMartini transforms invoice headers and lines, normalizes monetary values and dates, applies posting or notification rules, and handles retries with idempotent identifiers where available.
PaymentsRepresent payments associated with Bills, Vendors, Invoices, or Customers and support payment-status synchronization.ERP platforms, accounting ledgers, reporting databases, SlackMartini retrieves payment and related object details, maps BILL statuses explicitly, updates downstream systems, and routes ambiguous or failed transactions for reconciliation.
Purchase OrdersRepresent purchasing documents used to control or authorize spend.NetSuite, Sage Intacct, Microsoft Dynamics 365 Business Central, procurement workflowsMartini maps supplier, line, amount, and approval information, applies posting or authorization rules, and links the BILL identifier to the target purchase document.

Authentication and security considerations

OAuth 2.0 authentication

BILL application integrations use OAuth 2.0 with client credentials, access tokens, token expiration and refresh handling, and environment-specific application configuration. Confirm the current authorization flow, scopes, token endpoints, and sandbox requirements against the BILL developer documentation.

Secrets and permissions

Store BILL client credentials, tokens, and environment values in Martini secrets or secure environment configuration. Apply least-privilege scopes and account permissions, separating read-oriented synchronization from workflows that can create or process financial transactions.

Request validation

For webhook-style notifications, validate authenticity according to BILL’s current requirements, verify required identifiers and event fields, and retrieve the authoritative object before making material downstream changes.

Operational considerations for BILL integrations

Pagination and rate limits

Assume list operations may require pagination unless the resource documentation states otherwise. Process pages incrementally, control concurrency, and use retry delays and backoff for HTTP 429 responses or transient service errors.

Idempotency and financial status

Persist source references and BILL identifiers when creating or updating Bills, Invoices, and Payments. Map approval, payment, cancellation, and settlement statuses explicitly rather than treating them as interchangeable.

Webhooks and schema changes

Design for duplicate, delayed, and out-of-order notifications, incomplete event payloads, and follow-up resource retrieval. Version mappings, preserve unknown fields where appropriate, and test API-version or product changes against sandbox data before production deployment.

Amounts and attachments

Use decimal-safe handling for amounts, taxes, discounts, and payments, and normalize currency and date values explicitly. Confirm attachment encoding, file limits, temporary URL behavior, authentication, retention, and target-system requirements before implementing document transfer.

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

Orchestrate more than API calls

Martini coordinates BILL API consumption, webhook intake, pagination, enrichment, target writes, state management, validation, and reconciliation in maintainable workflows rather than scattering logic across scripts.

Separate mappings from business rules

Reusable mappings and workflow rules can normalize BILL financial objects for different ERPs, accounting platforms, databases, and notification channels while preserving BILL identifiers and lifecycle status.

Improve operational reliability

Martini provides a structured place to handle authentication, retries, throttling, duplicate prevention, logging, monitoring, and environment-specific configuration as integration requirements evolve.

Expose reusable APIs

Martini can expose a controlled API façade that presents normalized BILL data to internal applications, reducing point-to-point dependencies and allowing downstream consumers to remain insulated from BILL API details.

Frequently asked questions

How can BILL be integrated with enterprise systems?

BILL can be integrated through its OAuth 2.0-authenticated REST APIs, selected webhook-style event notifications, and document or attachment operations where the relevant endpoints are available. Scheduled workflows can retrieve paginated and changed resources such as Vendors, Customers, Bills, Invoices, Payments, and Purchase Orders, while event-driven workflows can process supported notifications.

Can Martini integrate with BILL?

Yes. Martini can consume BILL REST APIs, receive supported BILL webhook notifications, orchestrate scheduled or event-driven workflows, transform BILL JSON, and write normalized data to enterprise applications or databases. The exact operations depend on the BILL API version, product configuration, and account permissions.

Do I need a connector to integrate BILL with Martini?

No. A dedicated BILL connector is not required. Martini can integrate with BILL using BILL’s confirmed native mechanisms, including OAuth 2.0, REST APIs, selected webhook notifications, and supported attachment endpoints.

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

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

Which BILL integration methods should be used?

Use the BILL REST API as the primary integration method for Vendors, Customers, Bills, Invoices, Payments, and Purchase Orders. Use webhook-style notifications for confirmed events that require near-real-time processing, and use scheduled incremental synchronization or reconciliation when event coverage is unavailable or incomplete. No official BILL GraphQL or current SOAP capability was confirmed.

Can Martini receive BILL webhook events?

Martini can receive BILL webhook requests through an exposed API or webhook-consuming workflow. BILL notification coverage is selective, so the required event, payload structure, delivery behavior, and authenticity validation must be confirmed. A robust design retrieves the authoritative BILL object after receiving an identifier and handles duplicates or out-of-order delivery.

How does synchronization between BILL and another system work?

A Martini workflow can use BILL timestamps, status filters, pagination, and a persisted cursor or watermark when supported by the resource. It maps objects using stable BILL identifiers, upserts the target representation, and records synchronization state only after successful processing. Reconciliation workflows can address missed events, failed writes, and ambiguous financial transactions.

How does Martini handle BILL errors, retries, and duplicate financial records?

Martini can apply validation, controlled retries, backoff, throttling, logging, and failure routing in workflows. For Bills, Invoices, and Payments, integrations should persist source identifiers, BILL object IDs, and vendor-supported idempotency or deduplication values where available. Uncertain create responses should be reconciled before retrying to avoid duplicate financial records.

Related Martini documentation

BILL APIs

Workflows

Data

Security

Operations

Build a reliable BILL integration with Martini

Use Martini to connect BILL APIs and supported notifications with your accounting, ERP, CRM, database, and collaboration systems through secure workflows, reusable mappings, and controlled operational logic.

EXPLORE MARTINI
BOOK A DEMO