.png)
Brightpearl Integration Guide
Connect Brightpearl’s REST APIs and selected event notifications with commerce, fulfillment, finance, and enterprise applications through Martini workflows.
Brightpearl integration options at a glance
Brightpearl’s primary integration mechanism is its REST API, which provides access to operational and financial resources including Contacts, Sales Orders, Products, Inventory, Warehouses, and Purchase Orders. Brightpearl also supports webhook-style notifications for selected events, although event coverage must be confirmed for each resource and state transition. API access uses OAuth-based authentication with application credentials and Brightpearl account context. Martini can consume Brightpearl REST endpoints, receive supported notifications through an exposed API, transform payloads, apply validation and business rules, and coordinate scheduled reconciliation. Bulk, file, attachment, GraphQL, SOAP, and direct database mechanisms were not confirmed as general-purpose integration options.
| Integration point | Supported by Brightpearl? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Brightpearl’s principal integration mechanism for Contacts, Sales Orders, Products, Inventory, Warehouses, Purchase Orders, and other operational or financial resources. Use it for reads, writes, synchronization, and reconciliation. | Martini can consume Brightpearl REST endpoints from workflows, configure account-specific paths and OAuth credentials, paginate collection requests, transform payloads, and expose APIs that abstract Brightpearl request structures. |
| Webhooks / outbound callbacks | Limited | Brightpearl supports webhook-style event notifications for selected events. Coverage must be confirmed for the required resource and state transition. | Martini can expose an API endpoint to receive notifications, validate and deduplicate them, retrieve the current Brightpearl resource, and route the resulting event through a workflow. |
| Authentication | Yes | Brightpearl API access uses OAuth-based authentication with application registration, client credentials, bearer access tokens, account context, and account permissions. | Martini can store client credentials, tokens, account identifiers, and verification values in environment configuration or secrets and use them in secured API workflows. |
| Bulk / async / batch APIs | Not confirmed | The availability of bulk or asynchronous operations depends on the Brightpearl resource and current API documentation. Do not assume that every resource supports bulk writes or asynchronous jobs. | Where native bulk operations are unavailable, Martini can read pages incrementally, process bounded batches, record checkpoints, and retry only safe-to-repeat operations. |
| File / attachment APIs | Not confirmed | Brightpearl’s primary integration model is API-based. File or attachment support must be confirmed for the particular resource and document type. | Martini can coordinate separately supported file or storage services when needed and retain Brightpearl identifiers and file metadata alongside the workflow state. |
| GraphQL APIs | Not confirmed | No official Brightpearl GraphQL API was confirmed in the supplied research. REST APIs should be used unless current Brightpearl documentation identifies another supported interface. | Martini supports standards-based API consumption generally, but this Brightpearl integration should not depend on GraphQL without vendor confirmation. |
| SOAP APIs | Not confirmed | No official Brightpearl SOAP API was confirmed in the supplied research. SOAP should not be assumed as a Brightpearl integration mechanism. | Martini can consume SOAP services when provided by a system, but Brightpearl-specific implementation should use confirmed REST endpoints instead. |
| Database / analytics access | No | No public Brightpearl direct database-access mechanism was confirmed. Integrations should use supported Brightpearl APIs and event mechanisms. | Martini can connect to separate enterprise databases when required, but it should not bypass Brightpearl APIs through direct database access. |
How Brightpearl exposes data and business events
Brightpearl REST APIs
Brightpearl REST APIs are the primary documented mechanism for accessing operational and financial resources. They support integration work involving Contacts, Sales Orders, Products, Inventory, Warehouses, Purchase Orders, and additional Brightpearl resources, subject to endpoint-specific pagination, filtering, rate limits, and version behavior.
Martini implementation pattern
Martini uses a workflow to authenticate with OAuth credentials, call the appropriate account-specific Brightpearl endpoint, follow pagination, and transform the response into a canonical or downstream model. The workflow can validate fields, apply business rules, write to another application, and persist checkpoints for incremental synchronization and reconciliation.
Implementation sequence
Brightpearl webhook-style notifications
Brightpearl supports event notifications for selected events rather than every object or state transition. The required event and resource coverage should be confirmed before implementation, and scheduled reconciliation remains important for missed, delayed, or unsupported notifications.
Martini implementation pattern
Martini exposes an API endpoint for the Brightpearl notification, validates the request, checks for duplicate or out-of-order delivery, and retrieves the current Brightpearl object when the notification is not authoritative. The resulting object is then mapped, routed, and written to downstream systems with controlled retry handling.
Implementation sequence
Common Brightpearl integration patterns
Pattern 1: Synchronize Brightpearl Sales Orders with commerce platforms
When to use this pattern
Use this pattern when Brightpearl must exchange customer orders and order status with a storefront or marketplace. It supports scheduled retrieval or event-driven processing, while preserving line-level values and distinguishing order creation from payment, fulfillment, shipment, return, or cancellation states.
Integration direction
Example Mapping
| Brightpearl Field | Canonical Field | Target Field |
|---|---|---|
| Sales Order.id | externalOrderId | Shopify order reference |
| Sales Order.orderLines | lines | Shopify line items |
| Sales Order.status | orderState | Shopify fulfillment or order status |
| Sales Order.customerId | customerReference | Shopify customer ID |
Martini implementation pattern
A Martini workflow receives a Brightpearl notification where available or retrieves changed Sales Orders on a schedule. It fetches the current order, maps customer and line data, validates product identifiers and state transitions, and writes the result to the commerce platform. Stable correlation keys prevent duplicates, while transient failures are retried and business validation failures are routed for correction.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- validation
- error handling
- scheduled synchronization
Pattern 2: Publish Brightpearl inventory and products to sales channels
When to use this pattern
Use this pattern when Brightpearl is the operational source for catalog or inventory availability across storefronts, marketplaces, or fulfillment systems. The design should explicitly define whether downstream systems receive on-hand, allocated, reserved, available, or sellable quantities.
Integration direction
Example Mapping
| Brightpearl Field | Canonical Field | Target Field |
|---|---|---|
| Products.SKU | productCode | Shopify SKU |
| Products.price | sellingPrice | Shopify price |
| Inventory.quantity | availableQuantity | Shopify inventory level |
| Warehouses.id | locationReference | Shopify location |
Martini implementation pattern
Martini retrieves Products, Inventory, and Warehouses through paginated Brightpearl API calls, normalizes product and warehouse identifiers, calculates the configured downstream quantity, and publishes bounded updates. Rate-limit backoff, checkpointing, and scheduled reconciliation protect against missed changes and inventory drift.
Martini capabilities used
- workflows
- API consumption
- mapping and transformation
- business rules
- pagination handling
- rate-limit handling
- monitoring
Pattern 3: Process selected Brightpearl events in near real time
When to use this pattern
Use this pattern when a supported Brightpearl event should trigger lower-latency processing for an order, inventory, or other resource. Because Brightpearl notification coverage is selective, pair the event workflow with scheduled reconciliation.
Integration direction
Example Mapping
| Brightpearl Field | Canonical Field | Target Field |
|---|---|---|
| event.objectId | brightpearlObjectId | ShipStation order reference |
| Sales Order.orderLines | shipmentLines | ShipStation items |
| Sales Order.shippingAddress | deliveryAddress | ShipStation recipient address |
| Sales Order.status | fulfillmentEligibility | ShipStation order state |
Martini implementation pattern
An exposed Martini API accepts the Brightpearl notification, validates it, checks event idempotency, and retrieves the current object rather than trusting an incomplete payload. The workflow applies fulfillment eligibility rules, maps the order to ShipStation, records the processing outcome, and retries only transient downstream failures.
Martini capabilities used
- exposed APIs
- webhook consumption
- workflows
- data retrieval
- validation
- idempotency
- error handling
Pattern 4: Synchronize Brightpearl Contacts with a customer platform
When to use this pattern
Use this pattern when customer or supplier information must be shared with a CRM, service platform, or finance-related application. It is especially useful when field ownership differs across systems and bidirectional updates could otherwise overwrite authoritative values.
Integration direction
Example Mapping
| Brightpearl Field | Canonical Field | Target Field |
|---|---|---|
| Contacts.id | externalContactId | Salesforce external ID |
| Contacts.contactType | partyType | Salesforce contact classification |
| Contacts.addresses | postalAddresses | Salesforce address fields |
| Contacts.taxDetails | taxInformation | Salesforce tax-related fields |
Martini implementation pattern
Martini retrieves or receives Brightpearl Contacts, maps contact types and address structures, and applies field-level ownership rules before writing to Salesforce. External identifiers and processed timestamps prevent duplicate writes, while conflicts, missing references, and transient API failures are separated for resolution or retry.
Martini capabilities used
- workflows
- API consumption
- data mapping
- field ownership rules
- validation
- idempotency
- error handling
Applications commonly integrated with Brightpearl
Brightpearl can be integrated with commerce, marketplace, shipping, finance, sales, and customer service applications. The exact object coverage and system-of-record decisions should be confirmed for each implementation.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Shopify | Synchronize Products, inventory availability, customers, and Sales Orders between the storefront and Brightpearl’s retail operations platform. | Shopify → Martini → Brightpearl | Martini consumes Shopify changes or scheduled extracts, maps orders and customer data into Brightpearl REST requests, and separately publishes Brightpearl inventory and product updates back to Shopify. Idempotency keys and reconciliation checkpoints prevent duplicate orders and missed stock changes. |
| Magento / Adobe Commerce | Coordinate catalog, order, fulfillment, and inventory data between the commerce platform and Brightpearl. | Magento / Adobe Commerce → Martini → Brightpearl | A Martini workflow retrieves commerce orders and product changes, validates required identifiers, maps them to Brightpearl Products and Sales Orders, and synchronizes inventory or fulfillment status in the opposite direction. Failed writes are classified for retry or correction. |
| Amazon Seller Central | Synchronize marketplace orders, product listings, and inventory availability with Brightpearl’s operational records. | Amazon Seller Central → Martini → Brightpearl | Martini orchestrates marketplace API calls and Brightpearl REST requests, normalizes marketplace identifiers, and applies bounded batching for order and inventory workloads. Account-specific API limits and resource coverage are handled as deployment configuration. |
| eBay | Coordinate marketplace orders, inventory, and product information between eBay and Brightpearl. | eBay → Martini → Brightpearl | Martini maps eBay order and listing data to Brightpearl Sales Orders and Products, then sends selected availability updates back to eBay. Correlation keys and scheduled reconciliation address replayed events and incomplete notifications. |
| ShipStation | Send Brightpearl order and fulfillment information to shipping operations and return shipment status to Brightpearl. | Brightpearl → Martini → ShipStation | A Martini workflow retrieves eligible Brightpearl Sales Orders, transforms addresses and line items for ShipStation, and maps shipment or return updates back to Brightpearl. Business rules prevent shipment updates from overwriting incompatible order states. |
| NetSuite | Synchronize customers, products, sales orders, invoices, inventory, or financial data where both platforms participate in operational processes. | Brightpearl → Martini → NetSuite | Martini provides a canonical mapping layer between Brightpearl REST resources and NetSuite records, with explicit ownership rules for overlapping financial and inventory fields. Workflows validate state transitions and route rejected records for review. |
| Salesforce | Provide sales and service teams with Brightpearl Contacts, order summaries, fulfillment context, and selected customer updates. | Brightpearl → Martini → Salesforce | Martini retrieves or receives Brightpearl changes, maps Contacts and order summaries into Salesforce objects, and applies field-ownership rules for bidirectional customer synchronization. Retry handling separates transient API failures from validation errors. |
| Zendesk | Give support agents Brightpearl customer, order, fulfillment, and return information in the service workflow. | Brightpearl → Martini → Zendesk | Martini retrieves Brightpearl Contacts and Sales Orders, transforms relevant operational data into Zendesk customer or ticket context, and optionally processes selected service updates back through controlled workflows. Missing or stale Brightpearl objects are logged for reconciliation. |
How to build a Brightpearl integration in Martini
Objective
Establish Brightpearl API access using the required application registration, OAuth credentials, bearer token handling, account identifier, and permissions.
Instructions in Martini
- Store client credentials, account context, tokens, and verification values in Martini secrets or environment configuration.
- Configure the Brightpearl REST API request with the required account-specific path and bearer authentication.
- Confirm permissions and token refresh behavior against the Brightpearl account configuration.
Objective
Select event-driven processing, scheduled retrieval, or a combination based on the Brightpearl resource and required latency.
Instructions in Martini
- Use a Martini API endpoint for supported Brightpearl notifications.
- Use a Scheduler Trigger for incremental synchronization and reconciliation.
- Document which Brightpearl events are supported and which changes require polling.
Objective
Obtain the current Brightpearl object or collection data and preserve pagination and synchronization state.
Instructions in Martini
- Retrieve the current resource after a webhook notification when the notification is incomplete.
- Process collection pages until the endpoint indicates completion.
- Persist cursors, timestamps, identifiers, or other documented checkpoints.
Objective
Coordinate retrieval, validation, transformation, target writes, and recovery logic in a maintainable Martini workflow.
Instructions in Martini
- Separate event intake from downstream processing where asynchronous handling is useful.
- Apply conditional routing for object types, state transitions, and target systems.
- Keep Brightpearl-specific API details behind reusable workflow logic where practical.
Objective
Convert Brightpearl Contacts, Sales Orders, Products, Inventory, Warehouses, or Purchase Orders into the target model.
Instructions in Martini
- Map stable Brightpearl identifiers to external correlation keys.
- Transform addresses, line items, quantities, prices, statuses, and warehouse references.
- Preserve important unknown fields or explicitly document fields that are intentionally excluded.
Objective
Ensure that only valid and semantically correct changes are sent to downstream applications.
Instructions in Martini
- Validate required identifiers, state transitions, contact types, and quantity semantics.
- Define ownership rules for bidirectional customer, product, order, and inventory updates.
- Prevent duplicate processing of notifications, retries, and replayed messages.
Common Brightpearl data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Contacts | Synchronize customers, suppliers, addresses, tax details, contact types, and external identifiers. | Salesforce, Zendesk, Shopify, NetSuite, and finance-related applications | Martini maps contact types and address structures, applies field-ownership rules, validates identifiers, and uses stable keys to prevent duplicate updates. |
| Sales Orders | Exchange customer orders, order lines, quantities, prices, taxes, and order-state information. | Shopify, Magento / Adobe Commerce, Amazon Seller Central, eBay, ShipStation, and NetSuite | Martini retrieves or receives order changes, maps line-level data, distinguishes order, payment, fulfillment, and shipment states, and applies idempotency and retry rules. |
| Products | Synchronize catalog information, SKUs, variants, prices, and product-related data. | Shopify, Magento / Adobe Commerce, Amazon Seller Central, eBay, and NetSuite | Martini normalizes product identifiers and attributes, validates required fields, and routes rejected catalog changes for correction. |
| Inventory | Exchange stock quantities and availability, including warehouse-specific, allocated, reserved, or sellable quantities where supported by the model. | Shopify, marketplaces, fulfillment applications, ShipStation, and NetSuite | Martini applies explicit quantity semantics, maps warehouse context, throttles high-volume updates, and uses scheduled reconciliation to correct drift. |
| Warehouses | Represent locations used for inventory, fulfillment, and warehouse-specific availability. | Commerce platforms, fulfillment applications, marketplaces, and NetSuite | Martini maps Brightpearl warehouse identifiers to target locations and uses configuration-driven rules to determine which locations contribute to downstream availability. |
| Purchase Orders | Synchronize procurement transactions and supplier purchasing information. | NetSuite, finance applications, supplier systems, and reporting platforms | Martini validates supplier identifiers and order states, transforms line items and quantities, and records rejected or partially processed transactions for controlled recovery. |
Authentication and security considerations
OAuth-based API access
Brightpearl API access uses OAuth-based authentication with application registration, client credentials, bearer access tokens, account context, and account permissions. The exact authorization flow, token lifetime, refresh behavior, and permission model should be confirmed for the Brightpearl account.
Secret management
Store Brightpearl client credentials, access tokens, account identifiers, and any webhook verification values in Martini environment configuration or secrets rather than embedding them in workflows.
Inbound notification protection
Webhook-style notifications should be validated and authenticated according to Brightpearl’s supported request-verification approach. Martini should also apply idempotency checks before processing a notification.
Operational considerations for Brightpearl integrations
Rate limits and pagination
Brightpearl API requests may be throttled, and collection endpoints should be treated as paginated unless endpoint documentation states otherwise. Limit concurrency, use backoff, process all pages, and preserve checkpoints.
Idempotency and ordering
Duplicate or out-of-order notifications are possible considerations. Use durable event identifiers, Brightpearl object identifiers, or external correlation keys, and retrieve current object state when a notification is incomplete.
State consistency
Do not equate order creation with payment, fulfillment, invoicing, or shipment. Define explicit mappings for Sales Order, payment, fulfillment, shipment, return, and cancellation states, as well as on-hand, allocated, reserved, and sellable inventory quantities.
Schema changes and testing
Keep API versions configurable, validate required fields, monitor response-shape changes, and maintain contract tests for important Brightpearl objects. Separate business validation failures from transient technical failures.
Why use Martini instead of scripts or point-to-point integrations?
Reusable orchestration
Martini centralizes Brightpearl API calls, notification intake, pagination, transformations, target writes, business rules, and reconciliation in maintainable workflows rather than scattering logic across scripts.
Controlled data movement
Martini provides a place to define canonical mappings, field ownership, idempotency, state transitions, and bounded retry behavior for Contacts, Sales Orders, Products, Inventory, Warehouses, and Purchase Orders.
API-led integration
Martini can consume Brightpearl REST APIs and expose governed APIs for downstream applications, allowing Brightpearl-specific request structures to remain behind reusable enterprise integration assets.
Operational reliability
Scheduling, checkpoints, validation, error handling, monitoring, and reconciliation support production operation as Brightpearl data volumes, schemas, and downstream requirements change.
Frequently asked questions
Brightpearl is primarily integrated through its REST APIs, which expose operational and financial resources such as Contacts, Sales Orders, Products, Inventory, Warehouses, and Purchase Orders. Brightpearl also supports webhook-style notifications for selected events. OAuth-based authentication, scheduled synchronization, event processing, pagination, rate-limit handling, and reconciliation should be designed according to the specific account and resource.
Yes. Martini can integrate with Brightpearl by consuming its REST APIs and receiving supported Brightpearl webhook-style notifications. Martini can orchestrate workflows, map and transform Brightpearl data, apply business rules, expose an API endpoint for notifications, and synchronize data with downstream applications.
No. A dedicated Brightpearl connector is not required. Martini can use Brightpearl’s confirmed native integration mechanisms, including REST APIs, OAuth-based authentication, and supported webhook notifications, through standard API and workflow capabilities.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Brightpearl. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Brightpearl, cloud infrastructure, hosting, or other third-party systems depending on subscriptions, usage, and deployment model.
Brightpearl REST APIs are the primary and recommended integration method. Selected event notifications can support lower-latency processing, but coverage must be confirmed for each resource and state transition. No official Brightpearl GraphQL or SOAP mechanism was confirmed in the supplied research, and direct database access should not be used.
No such universal coverage was confirmed. Brightpearl supports webhook-style notifications for selected events, so the required resource and state transition must be checked before implementation. Scheduled incremental synchronization and reconciliation should supplement event processing where coverage is incomplete.
A Martini workflow can retrieve the current Brightpearl resource, map it to a canonical or target model, and apply explicit rules for identifiers, quantities, order states, payment, fulfillment, shipment, returns, and cancellations. Checkpoints, stable correlation keys, and scheduled reconciliation help manage pagination, missed events, and data drift.
Martini can classify authentication, authorization, rate-limit, validation, missing-resource, conflict, and transient network errors. Transient failures can be retried with controlled backoff, while business errors can be routed for correction. Martini can also expose a REST API façade that hides Brightpearl-specific request structures behind governed enterprise endpoints.
Related Martini documentation
APIs
Workflows
Connect Brightpearl with Martini
Use Brightpearl REST APIs and supported event notifications to build reliable, maintainable integrations with Martini workflows.