Ellipse Gradient for Header

Brex Integration Guide

Connect Brex financial data and selected event notifications with enterprise systems through REST APIs, webhooks, and Martini workflows.

Brex integration options at a glance

Brex primarily integrates with enterprise systems through authenticated REST APIs for Users, Cards, Card transactions, Expenses, Reimbursements, Payments, Receipts, and Spend programs. Brex also provides webhook-style notifications for selected products and events, although coverage varies by resource and lifecycle event. Martini can consume Brex JSON APIs, manage cursor-based pagination and incremental checkpoints, receive supported webhook requests through an exposed REST API, and orchestrate downstream processing. OAuth 2.0, bearer access tokens, scopes, and organization permissions govern access. Receipt-related APIs can support metadata and file workflows, while scheduled Martini workflows provide reconciliation, backfill, and recovery processing.

Integration pointSupported by Brex?Common use casesHow Martini supports it
REST APIsYesBrex's primary integration mechanism for retrieving Users, Cards, Card transactions, Expenses, Reimbursements, Payments, Receipts, and related resources, as well as supported write operations.Martini can consume Brex REST endpoints, authenticate requests, transform JSON, manage pagination, and route results to enterprise applications or exposed APIs.
Webhooks and outbound callbacksLimitedBrex provides webhook-style notifications for selected products and events, such as supported expense, transaction, or reimbursement changes. Coverage and payload completeness vary by product.Martini can expose a REST endpoint to receive supported Brex events, validate and deduplicate them, retrieve the current resource when necessary, and invoke downstream workflows.
File and attachment APIsLimitedReceipt-related API functionality can support receipt metadata and, depending on the endpoint, receipt downloads or submissions for applicable expense and transaction workflows.Martini can separate metadata processing from binary content handling, store or forward receipt files, and associate attachments with accounting or document records.
AuthenticationYesBrex uses authenticated HTTPS requests with OAuth-based authorization, bearer access tokens, scopes, and organization or user permissions.Martini can store credentials, tokens, endpoint configuration, and webhook verification data in secure environment configuration and orchestrate token lifecycle handling where refresh tokens are issued.
Scheduled synchronizationYesScheduled retrieval supports incremental synchronization, reconciliation, historical backfills, missed-event recovery, and resources without suitable webhook coverage.Martini can schedule workflows, retain cursors or timestamps after successful processing, apply bounded concurrency, and retry transient failures.
Bulk, asynchronous, or batch APIsNot confirmedEndpoint-specific bulk or asynchronous capabilities must be verified for the selected Brex product. List pagination should not be treated as a bulk API.Martini can orchestrate paginated or asynchronous workflows when the selected Brex endpoint documents those behaviors, but the API contract must be confirmed first.
Database or analytics accessNoNo direct Brex database connection or general-purpose database access is documented. Integrations should use Brex APIs and supported file or event mechanisms.Martini can persist checkpoints, audit data, or normalized results in an approved downstream database, but it does not require direct access to Brex's database.
SDKs and API definitionsLimitedBrex publishes developer documentation and API reference material. A machine-readable API definition may be available for selected products and should be verified before use.Martini can use confirmed API contracts as design references for requests, authentication, response schemas, and mappings; unsupported definitions should not be assumed.

How Brex exposes data and business events

Brex REST APIs

Brex's primary integration model is its REST API, which exposes resources including Users, Cards, Card transactions, Expenses, Reimbursements, Payments, Receipts, and Spend programs. Operations and fields depend on the Brex product, endpoint, and granted permissions.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates to Brex, retrieves or updates supported resources, follows endpoint-specific pagination, maps JSON into a canonical model, applies business rules, and writes to a target system. Checkpoints and source identifiers support incremental processing and reconciliation.

Implementation sequence

Authenticate the request with the configured Brex access token
Retrieve the selected Brex resource or submit a supported operation
Follow the endpoint-specific pagination or filtering controls
Map the Brex JSON response to the canonical integration model
Apply validation, accounting, approval, or status rules
Write the result to the target system and store the checkpoint

Brex webhook events

Brex provides webhook-style notifications for selected products and events. Event coverage is not universal, and a notification may contain either a complete object or an identifier requiring a follow-up API request.

Martini implementation pattern

Martini implementation pattern: expose a protected REST endpoint, validate the Brex request according to the selected product's documented verification method, durably accept the event, deduplicate it, retrieve current Brex data when needed, and route the normalized result to downstream systems.

Implementation sequence

Receive the supported Brex webhook notification
Validate authentication or the documented signing mechanism
Persist the event identifier and acknowledge durable acceptance
Retrieve the current Brex resource when the payload is incomplete or stale
Map and enrich the event for the target workflow
Route failures for retry or dead-letter handling

Brex scheduled synchronization

Scheduled synchronization is useful for incremental retrieval, reconciliation, historical backfills, missed-event recovery, and Brex resources without suitable webhook coverage. Pagination and filtering controls vary by endpoint.

Martini implementation pattern

Martini implementation pattern: a scheduler starts a workflow that loads the last successful cursor, timestamp, or object identifier, processes bounded pages, commits checkpoints only after successful writes, and records retry and reconciliation data.

Implementation sequence

Start the Martini workflow on a controlled schedule
Load the last successful Brex synchronization checkpoint
Retrieve the next endpoint-specific page or change set
Process each object with idempotent target writes
Persist the next cursor or equivalent checkpoint after success
Report exhausted pages, failures, and reconciliation totals

Brex receipt APIs

Brex supports receipt-related API functionality for applicable expense and transaction workflows. Depending on the endpoint, integrations may retrieve metadata, download content, or submit receipt content using a documented request format.

Martini implementation pattern

Martini implementation pattern: process receipt metadata with the parent transaction or Expense, retrieve binary content only when required, validate content type and size, and forward the attachment to an accounting or document system with durable association and retry handling.

Implementation sequence

Identify the Brex Expense or Card transaction requiring a receipt
Retrieve receipt metadata and confirm the applicable operation
Download or submit receipt content using the documented format
Validate file type, size, and source association
Store or forward the receipt to the target system
Record the attachment reference and retry any failed transfer

Common Brex integration patterns

Pattern 1: Export Brex transactions to an accounting platform

When to use this pattern

Use this pattern when finance teams need Card transactions synchronized to NetSuite, Microsoft Dynamics 365, or another accounting platform for reconciliation and reporting. It supports incremental processing and explicit treatment of pending, posted, declined, reversed, and corrected states.

Integration direction
Brex
Martini
NetSuite
Example Mapping
Brex FieldCanonical FieldTarget Field
Card transaction idsourceTransactionIdExternal transaction ID
amount and currencytransactionAmount and currencyCodeAmount and currency
statustransactionStatusTransaction status
user idcardholderIdEmployee reference
Martini implementation pattern

A scheduled Martini workflow retrieves changed Card transactions using the documented pagination and filtering model, enriches them with Users and Receipts where required, applies currency and accounting rules, and writes idempotently to the accounting platform. It stores cursors only after successful processing and routes transient failures to controlled retries.

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

Pattern 2: Process Brex webhook events

When to use this pattern

Use this pattern when supported Brex events should initiate near-real-time processing for Expenses, Card transactions, Reimbursements, or other documented resources. It should be combined with scheduled reconciliation because event coverage, delivery order, and payload completeness vary.

Integration direction
Brex
Martini
ServiceNow
Example Mapping
Brex FieldCanonical FieldTarget Field
event idsourceEventIdCorrelation or external event ID
resource identifiersourceObjectIdRelated record ID
event typeeventTypeCase or workflow category
resource statussourceStatusCase status
Martini implementation pattern

Martini exposes a protected REST endpoint, validates the event, durably records the event identifier, and retrieves the current Brex object when the notification is incomplete. The workflow applies routing and sensitivity rules before creating a deduplicated ServiceNow task or exception, with retry and dead-letter handling for downstream failures.

Martini capabilities used
  • REST API exposure
  • webhook consumption
  • workflows
  • deduplication
  • data enrichment
  • error handling

Pattern 3: Synchronize Brex Users and Cards with HR data

When to use this pattern

Use this pattern when Workday or another approved HR source must remain authoritative for employee status, department, manager, or card ownership decisions. It helps identify inactive-user assignments and organizational mismatches.

Integration direction
Workday
Martini
Brex
Example Mapping
Brex FieldCanonical FieldTarget Field
employee idemployeeIdBrex User identifier
employment statusemploymentStatusUser or card action rule
departmentdepartmentCodeBrex organizational attribute
manager idmanagerIdManager reference
Martini implementation pattern

A Martini workflow retrieves approved HR changes, matches them to Brex Users, compares Cards and assignments, and applies business rules for disabling, reassignment, or exception creation. It invokes only supported Brex operations and permissions, records decisions, and sends unresolved matches to manual review.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • business rules
  • validation
  • exception routing

Pattern 4: Export Brex reimbursements and expenses to an ERP

When to use this pattern

Use this pattern when approved Expenses and Reimbursements must be posted to an ERP with cost centers, tax information, vendors, employees, and accounting dimensions. It preserves audit references and supports controlled backfills.

Integration direction
Brex
Martini
Microsoft Dynamics 365
Example Mapping
Brex FieldCanonical FieldTarget Field
expense idsourceExpenseIdExternal document ID
employee or user idemployeeReferenceEmployee
approved amountapprovedAmountDocument amount
approval timestampapprovedAtApproval date
Martini implementation pattern

Martini retrieves approved or changed Expenses and Reimbursements, maps financial dimensions and currencies, validates required ERP fields, and writes the document with source-ID idempotency. It records target identifiers, status transitions, retry state, and reconciliation references for audit and correction processing.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • financial validation
  • idempotent writes
  • monitoring

Applications commonly integrated with Brex

Brex data can be coordinated with finance, HR, operational workflow, notification, and integration platforms. The exact operations and direction depend on Brex endpoint availability, permissions, and the target application's API.

Application Scenario Direction Martini Pattern
NetSuite Export Brex Expenses, Card transactions, Reimbursements, and accounting dimensions into NetSuite for reconciliation, reporting, and finance operations. Brex → Martini → NetSuite A scheduled Martini workflow retrieves incremental Brex data, enriches transactions with Users, Receipts, and accounting rules, maps the result to NetSuite objects, and applies idempotent writes with reconciliation and retry handling.
Workday Synchronize employee, department, manager, and employment-status information so Brex Users and Cards reflect the HR source of truth. Workday → Martini → Brex Martini retrieves approved Workday changes, matches them to Brex Users, applies business rules for inactive employees and card assignments, and invokes supported Brex REST operations where permissions allow.
Salesforce Associate selected Brex financial, approval, or employee-related information with Salesforce accounts, opportunities, or internal workflows when required by the business. Brex → Martini → Salesforce Martini consumes relevant Brex resources, normalizes the data, filters it using business rules, and exposes or writes a controlled Salesforce-facing workflow while avoiding unnecessary sensitive financial data.
ServiceNow Create requests, tasks, or exception cases for card access, expense issues, policy violations, and finance operations. Brex → Martini → ServiceNow A Martini webhook or scheduled workflow validates Brex events or changes, creates deduplicated ServiceNow cases, and records Brex and ServiceNow identifiers for status tracking.
Microsoft Dynamics 365 Send Brex Expenses, Reimbursements, Card transactions, and accounting classifications into finance and operations processes. Brex → Martini → Microsoft Dynamics 365 Martini retrieves and transforms Brex objects, maps currencies and accounting dimensions to Dynamics 365 fields, and uses checkpoints, idempotency, and exception routing for reliable delivery.
Ramp Compare or consolidate spend-management information during financial-system transitions, benchmarking, or multi-entity operations. Brex → Martini → Ramp Martini extracts authorized Brex data, applies a shared spend-data model, and delivers selected fields to Ramp or an intermediate data service subject to both products' API permissions.
Slack Notify finance teams and managers about approvals, exceptions, card events, and reimbursement status. Brex → Martini → Slack Martini receives supported Brex events or polls for status changes, applies notification rules, masks sensitive values, and sends concise messages through the approved Slack API flow.
Workato Coordinate Brex data with other enterprise applications where Workato is already part of the integration architecture. Brex → Martini → Workato Martini independently consumes Brex REST APIs or receives supported webhook events, then exchanges normalized payloads with Workato through agreed API boundaries rather than requiring a dedicated Brex connector.

How to build a Brex integration in Martini

Objective

Establish authenticated access to Brex and configure environment-specific endpoint, OAuth, bearer-token, scope, and webhook verification settings.

Instructions in Martini

  • Use Brex OAuth 2.0 or the authorized bearer access token method
  • Store client credentials, tokens, refresh data, and webhook verification data in secure Martini environment configuration
  • Apply least-privilege Brex scopes and organization permissions
  • Separate development, testing, and production configuration

Objective

Select webhook-driven, scheduled, or API-led execution according to the Brex resource and required processing latency.

Instructions in Martini

  • Use supported Brex webhook events for near-real-time processing
  • Use scheduled workflows for polling, reconciliation, backfills, and resources without suitable event coverage
  • Expose a Martini REST API when another system needs to initiate Brex processing
  • Confirm event coverage and endpoint filtering before finalizing the trigger

Objective

Receive or retrieve Brex resources while respecting endpoint-specific pagination, filtering, and file-handling behavior.

Instructions in Martini

  • Validate and durably accept webhook notifications before asynchronous processing
  • Retrieve the current Brex object when an event contains only an identifier or may be stale
  • Follow the pagination model documented for each Brex endpoint
  • Process receipt metadata and binary content as separate concerns

Objective

Coordinate transport, enrichment, business logic, target writes, and operational state in a maintainable Martini workflow.

Instructions in Martini

  • Keep API calls and pagination separate from business rules and mappings
  • Enrich Card transactions or Expenses with Users, Receipts, or related resources when required
  • Use bounded concurrency for high-volume synchronization
  • Persist cursors, source identifiers, event identifiers, and target references

Objective

Convert Brex JSON and receipt-related data into the canonical and target-system models without losing financial or audit context.

Instructions in Martini

  • Map stable Brex identifiers to external IDs in the target system
  • Preserve currency, amount, status, approval, and source timestamps
  • Handle pending, posted, rejected, declined, canceled, reversed, and corrected states explicitly
  • Validate required fields and isolate mappings from business rules

Objective

Apply accounting, approval, policy, security, and idempotency rules before committing data to downstream systems.

Instructions in Martini

  • Use source object or event identifiers for duplicate prevention
  • Apply target-specific currency, rounding, tax, and accounting rules
  • Mask tokens, receipt contents, full card numbers, and unnecessary personal data in logs
  • Route invalid or ambiguous objects to exception handling rather than silently dropping them

Common Brex data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
UsersRepresent employees or other people associated with a Brex organization and support ownership, approval, and organizational synchronization.Workday, identity platforms, NetSuite, Microsoft Dynamics 365Martini retrieves Users through REST APIs, maps identifiers and organizational attributes, applies employment-status rules, and preserves source identifiers for reconciliation.
CardsRepresent physical or virtual cards assigned to users, programs, or spending controls.Workday, ServiceNow, NetSuite, Microsoft Dynamics 365Martini synchronizes card ownership and status, flags assignments to inactive Users, and routes supported updates through Brex APIs only where permissions and endpoint operations allow.
Card transactionsCapture purchases and other card activity for categorization, reconciliation, policy processing, and accounting export.NetSuite, Microsoft Dynamics 365, data platforms, ServiceNowMartini retrieves transactions incrementally, handles pending, posted, declined, reversed, and corrected states, enriches them with Users and Receipts, and applies idempotent writes.
ExpensesRepresent employee or company expenses requiring review, accounting treatment, reimbursement, or export.NetSuite, Microsoft Dynamics 365, Salesforce, ServiceNowMartini consumes approved or changed Expenses, maps cost centers, tax information, vendors, and accounting dimensions, and routes validation failures for review.
ReimbursementsRepresent employee reimbursement requests and their approval or payment status.NetSuite, Microsoft Dynamics 365, Slack, ServiceNowMartini synchronizes status transitions, retains approval timestamps and target identifiers, and prevents duplicate exports through source-ID idempotency.
ReceiptsProvide receipt metadata or file content associated with Card transactions or Expenses.NetSuite, Microsoft Dynamics 365, document repositoriesMartini processes receipt metadata and binary content separately, validates content properties, stores or forwards files, and maintains the association with the source transaction or expense.

Authentication and security considerations

OAuth and bearer tokens

Brex APIs use authenticated HTTPS requests with OAuth-based authorization and bearer access tokens. Scopes and organization permissions restrict the resources and operations available to an integration.

Secure environment configuration

Store Brex client credentials, access tokens, refresh data, endpoint configuration, and webhook verification data in Martini environment configuration rather than workflow source or logs.

Webhook protection

Restrict the Martini endpoint that receives Brex callbacks and validate the authentication or signing mechanism documented for the selected Brex product and event type before processing payloads.

Data minimization

  • Use least-privilege Brex scopes and permissions.
  • Mask tokens, receipt contents, full card numbers, and unnecessary personal data in diagnostic output.
  • Define retention and deletion controls for receipts and financial data.

Operational considerations for Brex integrations

Rate limits and pagination

Confirm limits for each Brex endpoint, use bounded concurrency and exponential backoff for transient failures, and implement the pagination method documented for each resource. Commit cursors only after the corresponding page is processed successfully.

Idempotency and event delivery

Webhook deliveries may be retried or arrive out of order. Store event identifiers where available, use stable Brex object identifiers for polling, and use supported idempotency keys for create operations.

Financial and lifecycle data

Preserve original currencies and amounts, confirm whether each endpoint uses decimal values or minor units, and distinguish pending, approved, posted, rejected, declined, canceled, reversed, and corrected states.

Receipts and schema changes

Process receipt metadata separately from binary content, validate file properties, and maintain durable attachment references. Treat Brex responses as versioned external contracts and monitor status values, enum changes, pagination fields, and nested objects.

Testing and monitoring

  • Test representative pending, completed, rejected, reversed, and corrected objects.
  • Use reconciliation totals and source-to-target identifiers to detect omissions.
  • Monitor retries, webhook acceptance, downstream failures, and checkpoint progress.

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

Separate transport from business logic

Martini workflows can isolate Brex authentication, pagination, webhook reception, mappings, accounting rules, and target writes instead of embedding all behavior in a single script.

Support multiple execution models

The same integration design can combine REST API consumption, exposed Martini APIs, supported Brex webhook events, scheduled synchronization, backfills, and reconciliation workflows.

Improve maintainability

Reusable workflows, mappings, secure environment configuration, validation, checkpoints, and structured error handling make changes easier to test and operate than independent point-to-point scripts.

Preserve operational control

  • Apply idempotency and retry policies consistently.
  • Route invalid records and downstream failures for review.
  • Maintain audit references across Brex objects and target-system documents.
  • Monitor workflow execution and troubleshoot without coupling every target to Brex transport logic.

Frequently asked questions

How can Brex be integrated with enterprise systems?

Brex can be integrated primarily through authenticated REST APIs for Users, Cards, Card transactions, Expenses, Reimbursements, Payments, Receipts, and related resources. Brex also provides webhook-style notifications for selected products and events, while scheduled API synchronization supports reconciliation, backfills, and resources without suitable event coverage.

Can Martini integrate with Brex?

Yes. Martini can integrate with Brex by consuming its REST APIs, receiving supported Brex webhook events through an exposed Martini REST API, managing pagination and checkpoints, and transforming Brex data for downstream applications. A native Martini Brex connector is not confirmed in the supplied information.

Do I need a connector to integrate Brex with Martini?

No. A dedicated Brex connector is not required. Martini can use Brex's confirmed native integration mechanisms, including REST APIs, OAuth or bearer authentication, selected webhook events, receipt-related API operations, and scheduled workflows.

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

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

Which Brex integration methods should an enterprise use?

Use Brex REST APIs as the primary method for resource retrieval and supported writes. Use webhook-style notifications for selected events that require near-real-time processing, and combine them with scheduled polling for reconciliation, missed-event recovery, backfills, and resources without suitable webhook coverage. Brex GraphQL and SOAP APIs are not confirmed or supported in the supplied research.

Does Brex support webhooks or event notifications?

Brex supports webhook-style notifications for selected products and events, but coverage is not universal across all objects or lifecycle changes. The integration should verify event types, payload completeness, delivery retries, ordering, and authentication or signing requirements for the selected Brex product.

How does Martini synchronize Brex data and handle mapping?

Martini can run scheduled or event-driven workflows that retrieve Brex JSON, follow endpoint-specific pagination, retain cursors or timestamps, and map objects to canonical and target schemas. Workflows can preserve source identifiers, statuses, currencies, approval timestamps, and reconciliation references while applying target-specific business rules.

How are Brex errors, retries, and duplicate events handled?

Martini can apply bounded retries with exponential backoff for transient failures, persist webhook event identifiers, and use Brex object identifiers or supported idempotency keys to prevent duplicate writes. Workflows can distinguish validation failures from transient API errors, route unresolved items for review, and maintain logs and checkpoints for recovery.

Related Martini documentation

APIs

Events

Workflows

Security

Operations

Connect Brex with your enterprise systems

Use Martini to build governed Brex integrations that combine REST APIs, selected webhook events, scheduled synchronization, secure authentication, data mapping, and operational controls.

EXPLORE MARTINI
BOOK A DEMO