.png)
Marqeta Integration Guide
Connect Marqeta card-issuing and payment APIs with enterprise applications using REST workflows, selected webhook notifications, secure authentication, and scheduled synchronization.
Marqeta integration options at a glance
Marqeta’s Core API is primarily REST-based and supports operations for Users, Cards, Card Products, Transactions, Funding Sources, and related payment objects. Marqeta also provides webhook-style notifications for selected events, although coverage and delivery behavior depend on the product and event type. Some operations may support asynchronous or high-volume processing, but a universal bulk API was not confirmed. Martini can consume the REST API, receive selected webhook notifications through an exposed API or workflow trigger, map Marqeta JSON into canonical models, and run scheduled workflows for reconciliation. HTTP Basic Authentication with application and access tokens should be stored in protected Martini secrets.
| Integration point | Supported by Marqeta? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Marqeta’s primary integration model for creating and retrieving Users, issuing and managing Cards, retrieving Card Products, querying Transactions, managing Funding Sources, and processing payment-related operations. | Martini can consume Marqeta REST endpoints from workflows, map JSON responses, apply business rules, and expose internal APIs that invoke Marqeta operations. |
| Webhooks / outbound callbacks | Limited | Selected card-program and payment events can trigger webhook-style notifications, reducing the need to poll for every change. | Martini can expose a receiving API or webhook-triggered workflow, validate and deduplicate notifications, retrieve current Marqeta details when required, and route normalized events. |
| Bulk / async / batch APIs | Limited | Some payment and card-program operations may process asynchronously or support high-volume workflows, but a universal general-purpose bulk API was not confirmed. | Martini can coordinate endpoint-specific asynchronous processing, scheduled batching, pagination, checkpoints, bounded retries, and reconciliation without assuming bulk support for every operation. |
| Authentication | Yes | The Core API commonly uses an application token and access token with HTTP Basic Authentication over HTTPS, with separate sandbox and production environments. | Martini can store credentials in secrets or protected environment configuration and use environment-specific API settings without embedding tokens in workflows or logs. |
| GraphQL APIs | Not confirmed | No official Marqeta GraphQL API was confirmed in the supplied research. | Martini can consume GraphQL APIs when a provider exposes them, but Marqeta integration planning should use the documented REST API unless a separate product confirms GraphQL support. |
| SOAP APIs | Not confirmed | No official Marqeta SOAP API was confirmed in the supplied research. | Martini can consume SOAP services generally, but SOAP should not be used as a Marqeta integration method without product-specific confirmation. |
| File / attachment APIs | Not confirmed | A general-purpose file import, export, or attachment API for the primary Core API was not confirmed. | Martini should use Marqeta REST endpoints for operational data unless the relevant Marqeta product documentation identifies a supported file exchange. |
| Database / analytics access | Not confirmed | Direct access to Marqeta’s operational database was not confirmed; documented APIs or vendor-provided reporting facilities should be used instead. | Martini can retrieve data through Marqeta APIs and write normalized results to supported downstream databases without requiring direct Marqeta database access. |
How Marqeta exposes data and business events
Marqeta REST APIs
Marqeta’s Core API is primarily REST-based and provides operations for Users, Cards, Card Products, Transactions, Funding Sources, Payment Transactions, and related program data. The exact operations available depend on the Marqeta product, account permissions, and enabled program configuration.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates to the appropriate Marqeta sandbox or production environment, calls the required REST endpoint, validates the response, maps Marqeta JSON into a canonical model, applies business rules, and writes the result to an internal API, application, database, or finance platform.
Implementation sequence
Marqeta Webhook Notifications
Marqeta supports webhook-style notifications for selected events. Coverage is not universal across every object or event, and the payload may contain either complete details or only an identifier requiring a follow-up REST request.
Martini implementation pattern
Martini implementation pattern: Martini exposes a receiving API or webhook-triggered workflow, validates the notification according to the applicable Marqeta requirements, acknowledges it promptly, deduplicates the event, retrieves current Marqeta details when needed, and performs downstream processing asynchronously where appropriate.
Implementation sequence
Marqeta Asynchronous Processing
Some Marqeta payment and card-program operations may process asynchronously or support high-volume handling, but a universal bulk API was not confirmed. Endpoint-specific behavior must be verified before implementation.
Martini implementation pattern
Martini implementation pattern: a workflow submits an approved operation or retrieves data in controlled pages, records the correlation and processing state, and uses scheduled follow-up processing, bounded retries, and reconciliation to handle delayed or uncertain outcomes.
Implementation sequence
Marqeta Authentication
The Marqeta Core API commonly uses an application token and access token with HTTP Basic Authentication over HTTPS. Separate sandbox and production environments and credentials should be maintained.
Martini implementation pattern
Martini implementation pattern: Martini stores application credentials as protected secrets or environment configuration, selects the appropriate environment at deployment time, and keeps authentication material out of mappings, request bodies, source control, and logs.
Implementation sequence
Common Marqeta integration patterns
Pattern 1: Orchestrate card issuance
When to use this pattern
Use this pattern when a customer onboarding, account-management, or banking application needs to request a Marqeta card through a controlled enterprise API. The flow validates eligibility, selects the correct Card Product, creates or locates a User, issues a Card, and returns identifiers and status. Retries must not create duplicate Users or Cards after an uncertain network response.
Integration direction
Example Mapping
| Marqeta Field | Canonical Field | Target Field |
|---|---|---|
| external_customer_id | customerId | User identifier |
| card_product_code | cardProductCode | Card Product identifier |
| card_type | cardType | Card request attributes |
| requested_status | requestedLifecycleAction | Card lifecycle operation |
Martini implementation pattern
Martini exposes a controlled API that validates the request and invokes a workflow. The workflow looks up or creates the Marqeta User, selects an approved Card Product, calls the card operation, stores the correlation between internal and Marqeta identifiers, and returns a normalized response. Validation failures are rejected without retry; transient API failures use bounded retry and recovery handling.
Martini capabilities used
- APIs
- workflows
- API consumption
- data mapping
- business rules
- secrets management
- error handling
Pattern 2: Process transaction notifications
When to use this pattern
Use this pattern when selected Marqeta payment or card-program events should update support, risk, customer, or internal payment systems quickly. Because webhook coverage and payload completeness vary, the workflow treats the notification as a trigger and retrieves the current Transaction or related object when necessary.
Integration direction
Example Mapping
| Marqeta Field | Canonical Field | Target Field |
|---|---|---|
| event_id | sourceEventId | External event identifier |
| transaction_token | transactionId | Transaction reference |
| transaction_state | paymentLifecycleState | Ticket or case status |
| amount | transactionAmount | Transaction context |
Martini implementation pattern
Martini receives the selected webhook notification, authenticates and validates it, checks an idempotency store, and calls Marqeta when the payload lacks current details. It then applies rules for authorization, clearing, reversal, refund, or chargeback activity before updating Zendesk or publishing an internal event. Duplicate notifications are acknowledged without repeating downstream actions.
Martini capabilities used
- webhook-triggered workflows
- API consumption
- data mapping
- business rules
- idempotency
- error handling
Pattern 3: Synchronize card lifecycle data
When to use this pattern
Use this pattern when an internal account platform, CRM, or support application requires a reliable view of Marqeta Users and Cards. A scheduled workflow retrieves paginated data, uses an overlap window or endpoint-supported checkpoint, and performs idempotent upserts for new, changed, replaced, suspended, or closed cards.
Integration direction
Example Mapping
| Marqeta Field | Canonical Field | Target Field |
|---|---|---|
| user_token | customerId | Salesforce customer reference |
| card_token | cardId | Card external identifier |
| state | cardStatus | Card status |
| last_modified_time | sourceUpdatedAt | Last synchronized time |
Martini implementation pattern
A Martini scheduler starts the workflow and reads the persisted last-successful checkpoint. The workflow retrieves Marqeta pages, maps Users and Cards to Salesforce structures, applies status and ownership rules, upserts records using stable identifiers, and advances the checkpoint only after successful writes. Failed pages remain available for bounded retry and replay.
Martini capabilities used
- scheduled workflows
- pagination orchestration
- checkpointing
- data mapping
- business rules
- idempotent upserts
- monitoring
Pattern 4: Reconcile payment activity with finance
When to use this pattern
Use this pattern when finance teams need Marqeta Transactions, Payment Transactions, and Funding Sources reconciled with NetSuite or SAP S/4HANA. The workflow distinguishes authorization from clearing, settlement, reversal, refund, chargeback, rejected, and other documented lifecycle states rather than treating every transaction as final.
Integration direction
Example Mapping
| Marqeta Field | Canonical Field | Target Field |
|---|---|---|
| transaction_token | sourceTransactionId | External transaction ID |
| transaction_type | paymentLifecycleEvent | Transaction type |
| amount | amount | Amount |
| created_time | sourceTimestamp | Transaction date |
Martini implementation pattern
Martini runs a scheduled, paginated retrieval workflow, normalizes Marqeta payment data, enriches it with internal account and ledger mappings, and writes idempotently to NetSuite. It stores source identifiers and processing outcomes, routes validation failures separately from transient errors, and supports replay for incomplete or rejected batches.
Martini capabilities used
- scheduler triggers
- API consumption
- pagination
- data mapping
- transformation
- business rules
- retry handling
- audit logging
Applications commonly integrated with Marqeta
Marqeta is commonly positioned alongside customer, finance, banking, payment, and support applications in embedded-finance and card-program architectures. These are integration patterns rather than claims of native Marqeta integrations; Martini can orchestrate the confirmed Marqeta API and webhook mechanisms between the systems.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize customer, account, card, and service information so relationship and support teams can view card-program status. | Marqeta → Martini → Salesforce | Martini consumes Marqeta Users, Cards, and selected transaction notifications, maps them to Salesforce objects, and applies approved business rules before creating or updating records. Salesforce actions can be exposed through a Martini API that validates requests before calling Marqeta. |
| NetSuite | Reconcile card transactions, funding activity, fees, refunds, and settlement information with accounting records. | Marqeta → Martini → NetSuite | A scheduled Martini workflow retrieves paginated Transactions, Payment Transactions, and Funding Sources, separates authorization and settlement states, maps the results to NetSuite financial structures, and uses checkpoints and idempotent upserts to prevent duplicate postings. |
| Plaid | Support account verification, bank-account linking, or funding workflows associated with an embedded-finance product. | Plaid → Martini → Marqeta | Martini receives or retrieves approved Plaid results, validates the customer and funding context, applies program rules, and calls the relevant Marqeta REST endpoints. Correlation identifiers are retained so funding activity can be reconciled across both systems. |
| Stripe | Coordinate payment, funding, or settlement workflows where Marqeta-issued cards operate alongside Stripe payment processing. | Marqeta → Martini → Stripe | Martini normalizes Marqeta payment and transaction data with Stripe-related payment data, applies routing and reconciliation rules, and forwards only approved updates. Retry and duplicate controls protect against repeated payment-state changes. |
| SAP S/4HANA | Post transaction, funding, and settlement information into finance and treasury processes. | Marqeta → Martini → SAP S/4HANA | Martini retrieves Marqeta data on a schedule, enriches it with internal account mappings, transforms payment lifecycle states into SAP-compatible structures, and records processing checkpoints and rejected items for controlled replay. |
| Workday | Exchange worker, expense, or corporate-card-related information in employee card programs. | Workday → Martini → Marqeta | A Martini workflow receives eligible worker data from Workday or an internal source, validates program eligibility, creates or locates Marqeta Users, and coordinates Card issuance while returning Marqeta identifiers and status to the originating process. |
| Zendesk | Provide support agents with card status, transaction context, and customer-impacting event information. | Marqeta → Martini → Zendesk | Martini receives selected Marqeta notifications, retrieves current object details when necessary, maps card or transaction context into Zendesk, and exposes controlled support actions that validate authorization before invoking Marqeta operations. |
| Adyen | Coordinate broader payment acceptance or acquiring flows with Marqeta-issued card programs through an internal payments architecture. | Marqeta → Martini → Adyen | Martini acts as the orchestration layer between Marqeta and Adyen, normalizing payment states, routing approved events, and applying reconciliation and retry rules without assuming a native Marqeta–Adyen integration. |
How to build a Marqeta integration in Martini
Objective
Establish separate sandbox and production connections to Marqeta using the Core API authentication model and protected environment configuration.
Instructions in Martini
- Configure the Marqeta API environment and base settings.
- Store the application token and access token in Martini secrets.
- Use HTTPS and keep credentials out of mappings, source control, request bodies, and logs.
- Confirm endpoint permissions and account-level enablement before production use.
Objective
Select an event-driven, API-led, or scheduled entry point based on the integration’s timing and Marqeta coverage requirements.
Instructions in Martini
- Use a receiving Martini API or webhook-triggered workflow for selected Marqeta notifications.
- Use an exposed Martini API for controlled card-management requests from internal applications.
- Use a scheduler for reconciliation and incremental User, Card, Transaction, or Funding Source synchronization.
- Do not assume every Marqeta object or event supports webhook delivery.
Objective
Call the relevant Marqeta REST endpoint and retrieve complete data while accounting for pagination, asynchronous processing, and endpoint-specific behavior.
Instructions in Martini
- Invoke the documented REST operation for the required Marqeta object.
- Process collection endpoints page by page.
- Persist a checkpoint and use an overlap window where late-arriving data could cause missed records.
- Confirm whether an operation is asynchronous before designing polling or follow-up processing.
Objective
Coordinate the API calls, event handling, correlation identifiers, and downstream operations in a maintainable Martini workflow.
Instructions in Martini
- Separate request acceptance from longer-running processing where appropriate.
- Retrieve current Marqeta details when a webhook payload contains only an identifier.
- Store internal-to-Marqeta correlation identifiers.
- Use conditional routing for valid, rejected, asynchronous, and recoverable outcomes.
Objective
Convert Marqeta JSON objects and payment lifecycle states into canonical and target-system structures.
Instructions in Martini
- Map Users, Cards, Card Products, Transactions, Funding Sources, and Payment Transactions explicitly.
- Normalize timestamps, identifiers, amounts, and lifecycle states.
- Preserve source event and transaction identifiers for auditability.
- Retain useful unknown fields where forward compatibility requires them.
Objective
Enforce program, eligibility, lifecycle, reconciliation, and duplicate-processing rules before writing to downstream systems or changing Marqeta state.
Instructions in Martini
- Validate required fields and approved Card Product selections.
- Distinguish authorization, clearing, reversal, refund, chargeback, and settlement activity.
- Check idempotency keys or persisted source identifiers before applying updates.
- Reject non-transient validation or authorization failures without blind retries.
Common Marqeta data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Users | Represent cardholders or account holders associated with a Marqeta card program. | Salesforce, Workday, customer applications, banking platforms | Martini retrieves, creates, or updates Users through REST workflows, validates identity and program rules, and maintains correlation between internal and Marqeta identifiers. |
| Cards | Represent physical or virtual payment cards issued to Users, including lifecycle and status information. | Salesforce, Zendesk, customer applications, banking platforms | Martini orchestrates card issuance or lifecycle synchronization, applies approval rules, maps card status changes, and uses idempotent processing to avoid duplicate issuance. |
| Card Products | Define configuration templates and controls governing card behavior and program rules. | Internal program administration, customer applications, banking platforms | Martini retrieves Card Products to select or validate the appropriate program configuration before card issuance and can cache approved mappings in an internal configuration store. |
| Transactions | Represent authorization, clearing, reversal, and related payment activity. | NetSuite, SAP S/4HANA, data stores, risk and support applications | Martini retrieves paginated Transactions, distinguishes lifecycle states, normalizes fields, applies reconciliation rules, and preserves source identifiers for auditability. |
| Funding Sources | Represent sources used to fund or support payment activity. | NetSuite, SAP S/4HANA, banking platforms, internal payment services | Martini synchronizes Funding Sources through protected workflows, validates permitted relationships, and maps funding activity to downstream finance or payment models. |
| Payment Transactions | Represent payment and transfer-related activity exposed through Marqeta payment APIs. | NetSuite, SAP S/4HANA, payment platforms, internal ledgers | Martini retrieves and transforms Payment Transactions, separates successful and rejected activity, and applies checkpointing and retry controls during reconciliation. |
Authentication and security considerations
Marqeta authentication
The Marqeta Core API commonly uses an application token and access token with HTTP Basic Authentication over HTTPS. OAuth 2.0 and JWT bearer authentication were not confirmed as the standard Core API mechanism.
Credential protection
- Store application and access tokens in Martini secrets or protected environment configuration.
- Maintain separate sandbox and production credentials and endpoints.
- Do not embed credentials in workflows, mappings, source control, request bodies, or logs.
- Confirm endpoint permissions and account-level enablement for the selected Marqeta product.
Operational considerations for Marqeta integrations
Pagination and checkpoints
Collection endpoints may be paginated. Use persisted checkpoints, overlap windows where necessary, and deduplication to reduce the risk of missed or repeated Users, Cards, Transactions, or Funding Sources.
Idempotency and lifecycle state
Use stable Marqeta identifiers and correlation tables to make retries safe. Do not treat an authorization as a settled transaction; distinguish clearing, reversals, refunds, chargebacks, and other documented states.
Webhooks and retries
Selected webhook notifications should be validated, acknowledged promptly, deduplicated, and followed by a REST lookup when the payload does not contain sufficient detail. Apply bounded exponential backoff to transient failures and avoid retrying non-transient validation errors.
API and schema changes
Test issuance, transaction retrieval, webhook delivery, and failure paths in the sandbox. Monitor Marqeta documentation and release information for changes to fields, statuses, event payloads, permissions, and endpoint behavior.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond a script
Martini separates triggers, API calls, transformations, business rules, downstream writes, and recovery paths into maintainable workflows. This is useful when Marqeta data must be coordinated across customer, finance, banking, payment, and support applications.
Reliable synchronization
Workflows can combine scheduled retrieval, pagination, checkpoints, idempotent upserts, webhook processing, and bounded retries. These controls are difficult to standardize across isolated scripts and point-to-point integrations.
Reusable APIs and mappings
Martini can expose a controlled API façade over Marqeta, centralize validation and authorization, map Marqeta JSON into canonical models, and reuse integration logic across multiple downstream systems.
Frequently asked questions
Marqeta can be integrated primarily through its REST-based Core API for Users, Cards, Card Products, Transactions, Funding Sources, Payment Transactions, and related operations. Marqeta also provides webhook-style notifications for selected events. Enterprise workflows can combine API calls, selected notifications, scheduled synchronization, pagination, checkpointing, and downstream mapping.
Yes. Martini can integrate with Marqeta by consuming its REST APIs, receiving selected webhook notifications, exposing internal APIs, orchestrating workflows, mapping Marqeta JSON, and writing normalized results to downstream applications or databases. A native Martini Marqeta connector was not confirmed.
No. A dedicated Marqeta connector is not required. Martini can use Marqeta’s confirmed native integration mechanisms, including the Core REST API, selected webhook notifications, HTTP Basic Authentication, and scheduled API workflows.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Marqeta. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Marqeta, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
The Marqeta Core REST API is the primary method for operational integrations involving Users, Cards, Card Products, Transactions, Funding Sources, and Payment Transactions. Selected webhook-style notifications can reduce polling for supported events, while scheduled REST workflows remain important for reconciliation and reliable synchronization. GraphQL and SOAP support were not confirmed.
No. Marqeta supports webhook-style notifications for selected events, but coverage, delivery behavior, payload completeness, and authentication requirements depend on the product and event type. An implementation should verify the required events and retrieve the current Marqeta resource when a notification is not self-contained.
Martini can run scheduled workflows that retrieve paginated Marqeta collections, persist a last-successful checkpoint, use an overlap window where appropriate, map objects into canonical models, and perform idempotent upserts. Transaction reconciliation should distinguish authorization, clearing, reversal, refund, chargeback, and settlement activity.
Martini can separate transient transport or service failures from validation and authorization errors, apply bounded retries with backoff, and route unrecoverable items for review. Idempotent workflows should persist Marqeta event, transaction, User, or Card identifiers so duplicate notifications or uncertain retries do not repeat business actions. Martini can also expose an API façade over Marqeta that applies organization-specific validation and authorization.
Related Martini documentation
Workflows
Connect Marqeta with the rest of your enterprise landscape
Use Martini to orchestrate Marqeta REST APIs and selected webhook notifications into secure, observable workflows for card issuance, transaction processing, lifecycle synchronization, and reconciliation.