.png)
Supabase Integration Guide
Integrate Supabase with enterprise systems through its REST, GraphQL, PostgreSQL, Storage, and selective Database Webhook capabilities.
Supabase integration options at a glance
Supabase provides several standards-based integration paths for enterprise workloads. Its PostgREST layer exposes PostgreSQL tables and functions through REST APIs, while the pg_graphql extension provides GraphQL queries and mutations where enabled. Martini can also connect directly to Supabase PostgreSQL for controlled SQL processing, batching, reporting, or migration workloads. Supabase Database Webhooks can notify an exposed Martini API about selected table inserts, updates, and deletes. Storage APIs support bucket and object operations, including uploads, downloads, listings, and signed URLs. Martini workflows can authenticate with securely managed API keys, JWTs, or PostgreSQL credentials, then map, validate, synchronize, and monitor the resulting data flows.
| Integration point | Supported by Supabase? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Supabase automatically exposes PostgreSQL tables and database functions through PostgREST. Use REST for querying, inserting, updating, deleting, upserting, and invoking supported functions. | Martini can consume Supabase REST endpoints, add the required apikey and bearer headers, paginate results, map payloads, and orchestrate downstream writes. |
| GraphQL APIs | Yes | The pg_graphql extension exposes configured PostgreSQL schema objects through GraphQL queries and mutations subject to database permissions and policies. | Martini can consume the Supabase GraphQL endpoint when pg_graphql is enabled, then transform query results or mutation responses in workflows. |
| Webhooks / outbound callbacks | Limited | Database Webhooks can issue HTTP requests for selected table inserts, updates, and deletes. They are not a universal event stream for every Supabase product event. | Martini can expose an API or webhook receiver workflow, validate the callback, apply business rules, and route the event to other systems. |
| Database access | Yes | Supabase provides direct PostgreSQL connectivity for controlled batch processing, reporting, migration, and workloads better suited to SQL than HTTP APIs. | Martini can connect through JDBC where network access, SSL, pooling, credentials, and PostgreSQL permissions are configured correctly. |
| File / attachment APIs | Yes | Supabase Storage supports bucket and object creation, upload, download, listing, copying, moving, removal, and signed URL generation. | Martini can call Storage endpoints, validate metadata, transform file content, and coordinate object transfers with APIs, databases, or file endpoints. |
| Bulk / async / batch APIs | Limited | Supabase has no confirmed separate general-purpose enterprise bulk API. Bulk-style processing can use multi-row REST operations, upserts, SQL transactions, direct PostgreSQL access, and application-managed batching. | Martini can implement controlled pagination, batching, transactions, checkpoints, and retry handling while respecting database capacity and connection limits. |
| Authentication | Yes | Supabase uses API keys, JWT bearer tokens, Auth identities, Row Level Security, and PostgreSQL credentials depending on the interface and authorization model. | Martini can store credentials in secrets, send apikey and Authorization headers, use least-privileged roles, and preserve an end-user JWT when required. |
| Realtime data delivery | Limited | Supabase Realtime supports selected database changes and realtime channels over persistent WebSocket connections. It should be distinguished from ordinary HTTP Database Webhooks. | Martini can directly govern HTTP-based callbacks and scheduled reads; WebSocket-based Realtime use requires separate deployment and connectivity assessment. |
How Supabase exposes data and business events
Supabase REST APIs
Supabase automatically exposes PostgreSQL tables and supported database functions through a PostgREST-powered REST interface. REST requests commonly use a project URL, an apikey header, and optionally a bearer token that determines the authenticated user and Row Level Security context.
Martini implementation pattern
Martini uses a workflow to call the relevant table or RPC endpoint, select and page through data, apply validation and transformations, and write results to downstream systems. Credentials and project configuration remain in environment secrets, while stable keys and checkpoints support repeatable synchronization.
Implementation sequence
Supabase GraphQL APIs
When the pg_graphql extension is enabled, Supabase exposes configured PostgreSQL schema objects through GraphQL queries and mutations. Available fields and operations depend on database permissions, schema configuration, and Row Level Security policies.
Martini implementation pattern
Martini can consume the GraphQL endpoint for structured queries or mutations when GraphQL is appropriate for the workload. A workflow validates the response, handles GraphQL errors, maps nested data, and routes the result to databases or applications.
Implementation sequence
Supabase Database Webhooks
Supabase Database Webhooks send HTTP requests for configured PostgreSQL table events, commonly inserts, updates, and deletes. Coverage is selective and should not be treated as a universal notification mechanism for Auth, Storage, or all platform events.
Martini implementation pattern
Martini exposes an API endpoint or webhook receiver workflow for the callback. The workflow validates the request, event type, table, operation, and payload, then applies business rules and routes accepted events to downstream applications or queues.
Implementation sequence
Supabase PostgreSQL
Supabase provides direct PostgreSQL connectivity for SQL-oriented workloads such as controlled batch processing, reporting, migrations, and large transfers. Access depends on network reachability, SSL, pooling, roles, and database permissions.
Martini implementation pattern
Martini uses JDBC-backed workflow database operations to read or write PostgreSQL data within controlled transaction boundaries. The workflow can combine SQL operations with API calls, mappings, validation, and reconciliation logic without holding connections across long-running steps.
Implementation sequence
Supabase Storage APIs
Supabase Storage provides APIs for buckets and objects, including upload, download, listing, copying, moving, deletion, and signed URLs. Business metadata and object paths are commonly maintained in PostgreSQL tables alongside the binary content.
Martini implementation pattern
Martini orchestrates object retrieval or upload with metadata validation and downstream delivery. Workflows can parse CSV or JSON files, call other APIs or databases, and persist processing results while keeping temporary access controlled through signed URLs where appropriate.
Implementation sequence
Common Supabase integration patterns
Pattern 1: Synchronize Supabase customers with a CRM
When to use this pattern
Use this pattern when customer or profile data is stored in Supabase tables and must be created or updated in a CRM such as Salesforce. A scheduled workflow is appropriate when changes are not required immediately or when reconciliation is more important than event latency.
Integration direction
Example Mapping
| Supabase Field | Canonical Field | Target Field |
|---|---|---|
| id | customer.externalId | External_Id__c |
| customer.email | ||
| created_at | customer.createdAt | CreatedDate |
| updated_at | customer.updatedAt | LastModifiedDate |
Martini implementation pattern
Martini pages through Supabase REST results or reads PostgreSQL using a stable timestamp or identifier checkpoint. It validates required fields, maps the row into a canonical customer model, applies matching and eligibility rules, and performs an idempotent Salesforce upsert. The workflow stores the target identifier and checkpoint, retries transient failures, and routes invalid records for review.
Martini capabilities used
- scheduled workflows
- REST API consumption
- JDBC connectivity
- data mapping
- business rules
- idempotent upserts
- checkpointing
- error handling
Pattern 2: Process Supabase database changes
When to use this pattern
Use this pattern when selected inserts, updates, or deletes should trigger downstream business processing without repeatedly scanning the full database. It is suitable for operational events covered by Supabase Database Webhooks.
Integration direction
Example Mapping
| Supabase Field | Canonical Field | Target Field |
|---|---|---|
| table | event.sourceTable | u_source_table |
| type | event.operation | u_operation |
| record.id | event.subjectId | correlation_id |
| record.status | event.status | state |
Martini implementation pattern
A Supabase Database Webhook calls a secured Martini API. Martini validates the callback and derives a deterministic event key before applying routing rules. It maps qualifying changes into a ServiceNow request or incident, records the external identifier back in Supabase, and treats duplicate deliveries as already processed rather than creating duplicate work.
Martini capabilities used
- API exposure
- webhook consumption
- workflow orchestration
- validation
- data mapping
- conditional routing
- idempotency
- retry handling
Pattern 3: Exchange files through Supabase Storage
When to use this pattern
Use this pattern when Supabase Storage contains imports, exports, documents, or generated files that must be processed by enterprise applications. The same workflow structure can support both inbound retrieval and outbound upload.
Integration direction
Example Mapping
| Supabase Field | Canonical Field | Target Field |
|---|---|---|
| name | file.objectPath | externalFileReference |
| metadata.mimetype | file.contentType | documentType |
| metadata.size | file.size | fileSize |
| created_at | file.createdAt | receivedAt |
Martini implementation pattern
Martini identifies the object, validates its path and metadata, retrieves the content, and parses or transforms it before calling the target API. It can write a processing status and object reference to a Supabase table, use signed URLs for temporary access, and quarantine or retry files that fail validation or transfer.
Martini capabilities used
- workflow orchestration
- Storage API consumption
- file processing
- JSON handling
- mapping and transformation
- validation
- retry handling
- status persistence
Pattern 4: Orchestrate Supabase data with an external payment API
When to use this pattern
Use this pattern when Supabase holds application orders or customer state and an external payment platform such as Stripe must authorize or record a payment. It supports an API-led flow with durable status updates and reconciliation.
Integration direction
Example Mapping
| Supabase Field | Canonical Field | Target Field |
|---|---|---|
| id | order.orderId | metadata.order_id |
| customer_id | order.customerId | customer |
| total_amount | order.amount | amount |
| payment_status | payment.status | payment_intent.status |
Martini implementation pattern
A Martini API or scheduled workflow reads a Supabase order, validates its status and amount, calls Stripe, and writes the returned payment identifier and status back to Supabase. Business rules prevent reprocessing completed orders, while retries and reconciliation handle timeouts or ambiguous responses without issuing duplicate payment actions.
Martini capabilities used
- API exposure
- REST API consumption
- workflow orchestration
- data mapping
- business rules
- idempotency
- reconciliation
- error handling
Applications commonly integrated with Supabase
Supabase is commonly used as an application backend, so integrations typically connect its PostgreSQL data, Auth identities, Storage objects, and database events with adjacent business and development platforms. The following are practical enterprise architecture patterns rather than claims of dedicated native integrations.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Stripe | Synchronize customer, product, subscription, invoice, and payment status data with application tables and billing workflows. | Stripe → Martini → Supabase | Receive selected Stripe webhook events or call Stripe APIs from a Martini workflow, validate the payload, map billing identifiers to Supabase tables, and use idempotent REST or PostgreSQL upserts. A reverse workflow can read Supabase application state and create or update Stripe billing objects. |
| Vercel | Support frontend applications deployed on Vercel that use Supabase for database access, authentication, and storage. | Vercel → Martini → Supabase | Use Martini APIs and workflows for controlled server-side orchestration between Vercel applications and Supabase. Keep Supabase credentials in secrets, validate incoming requests, and expose only the operations required by the application. |
| GitHub | Persist repository, deployment, issue, or application-event data in Supabase for internal portals, operational workflows, and reporting. | GitHub → Martini → Supabase | Receive GitHub webhook requests through a Martini API or retrieve GitHub data on a schedule, normalize event payloads, and write application data to Supabase through REST, GraphQL, or PostgreSQL with checkpointing and duplicate protection. |
| Auth0 | Coordinate identity information when Auth0 is used as an external identity provider alongside a Supabase-backed application. | Auth0 → Martini → Supabase | Validate Auth0 tokens or event payloads in Martini, apply identity mapping rules, and synchronize only the required user attributes with Supabase Auth-related application data. Authorization boundaries should remain explicit for each system. |
| Salesforce | Synchronize customer, account, or operational data between a Supabase-backed application and Salesforce. | Supabase → Martini → Salesforce | Use a scheduled Martini workflow or Supabase Database Webhook to detect relevant changes, transform PostgreSQL rows into Salesforce API payloads, apply business rules, and persist Salesforce identifiers and synchronization status in Supabase. |
| ServiceNow | Send application or database events into ServiceNow incident, request, or workflow processes and return selected status information. | Supabase → Martini → ServiceNow | Receive a Supabase Database Webhook in Martini, validate the table operation and payload, map the event to a ServiceNow request or incident, and write the ServiceNow identifier and status back to Supabase. Retry transient failures without duplicating tickets. |
| Shopify | Synchronize catalog, order, customer, and fulfillment data for custom commerce applications backed by Supabase. | Shopify → Martini → Supabase | Consume Shopify webhooks or APIs in Martini, normalize commerce objects, and upsert them into Supabase tables. Reverse workflows can use validated Supabase state to submit selected updates to Shopify while recording external identifiers. |
| NetSuite | Persist application transaction data in Supabase while synchronizing finance or fulfillment information with NetSuite. | Supabase → Martini → NetSuite | Use scheduled or event-driven Martini workflows to read Supabase data, transform it into NetSuite requests, and store response identifiers and processing state. Apply retry, reconciliation, and controlled batching for financial or fulfillment workloads. |
How to build a Supabase integration in Martini
Objective
Establish the Supabase connection using the authentication model appropriate for the workflow, while keeping project URLs, API keys, JWT material, and database credentials outside the workflow definition.
Instructions in Martini
- Choose REST, GraphQL, Storage, or PostgreSQL access for the workload
- Store credentials and project configuration in Martini secrets or environment configuration
- Use a least-privileged key, JWT, or PostgreSQL role
- Confirm network, SSL, pooling, and Row Level Security requirements
Objective
Select an event, API, or schedule that matches the required latency and the coverage available from Supabase.
Instructions in Martini
- Use a Martini API or webhook receiver for selected Database Webhook events
- Use a scheduler for reconciliation and incremental synchronization
- Use REST or GraphQL retrieval for application-driven requests
- Treat Realtime WebSocket requirements separately from HTTP webhook processing
Objective
Acquire Supabase data or files with bounded requests and enough context to support reliable downstream processing.
Instructions in Martini
- Page REST results and select only required fields
- Validate GraphQL responses at both transport and GraphQL levels
- Use bounded SQL queries and transaction scopes for PostgreSQL access
- Retrieve Storage objects with validated paths and metadata
Objective
Coordinate calls, transformations, routing, and persistence as a maintainable Martini workflow rather than embedding the entire process in a one-off script.
Instructions in Martini
- Normalize incoming payloads into a canonical model
- Use conditional routing for event types, statuses, and business ownership
- Separate reusable API and transformation logic where appropriate
- Persist checkpoints, external identifiers, and processing status
Objective
Convert Supabase rows, GraphQL results, webhook payloads, or Storage files into the target system's contract.
Instructions in Martini
- Map actual Supabase fields such as table columns, Users, or Storage object metadata
- Parse JSON or CSV content when files are exchanged
- Validate required fields, types, and identifiers before writing
- Apply compatibility logic when database schema changes affect mappings
Objective
Enforce authorization, deduplication, eligibility, and reconciliation rules before external side effects occur.
Instructions in Martini
- Respect Row Level Security and distinguish user JWTs from elevated service credentials
- Use deterministic keys or event identifiers for idempotent processing
- Prevent duplicate payment, ticket, or customer actions
- Route invalid or unauthorized events to controlled error handling
Common Supabase data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Projects | Represent Supabase environments containing a PostgreSQL database, APIs, authentication configuration, storage, and project settings. | Configuration management platforms, deployment workflows, monitoring systems | Martini can use project-specific URLs and credentials from environment configuration, while keeping operational metadata separate from application data. |
| Organizations | Group projects, members, and billing information at the Supabase account level. | Administrative systems, reporting platforms, identity and access workflows | Martini can retrieve or synchronize organization-level information through confirmed Supabase management interfaces when available, without assuming it is exposed through application table APIs. |
| Users | Represent authenticated identities managed by Supabase Auth and associated application profiles. | Auth0, Salesforce, application databases, identity workflows | Martini can process user-related API data using the appropriate JWT or server credential and apply explicit identity mapping and authorization rules. |
| Tables and rows | Store application data in PostgreSQL and expose it through generated REST and GraphQL APIs. | Salesforce, ServiceNow, Shopify, NetSuite, data warehouses | Martini can query or mutate rows through REST or GraphQL, or use JDBC for controlled SQL workloads, with mappings, pagination, upserts, and checkpoints. |
| Storage buckets and objects | Manage files, documents, exports, and other binary content through Supabase Storage. | Document systems, file endpoints, APIs, PostgreSQL metadata tables | Martini can list, retrieve, upload, move, copy, remove, and sign object URLs while synchronizing object paths and business metadata separately. |
| Realtime channels and database changes | Deliver selected database changes and channel messages to subscribed applications over realtime connections. | Event processing services, application backends, notification workflows | Martini can process HTTP Database Webhook events directly; Realtime WebSocket consumption requires separate assessment and should not be treated as a standard webhook flow. |
Authentication and security considerations
Credential choices
Supabase access depends on the interface and authorization model. Martini can use API keys, JWT bearer tokens, or PostgreSQL credentials stored in secure environment configuration.
Least privilege and Row Level Security
Use the least-privileged key or database role that supports the workflow. REST and GraphQL requests can be affected by PostgreSQL Row Level Security, so test with the same user or service identity used in production.
Protect elevated credentials
- Never expose a service_role key or current secret-key equivalent to browsers or untrusted clients.
- Keep Supabase URLs, keys, JWT material, and database credentials in Martini secrets.
- Use end-user JWTs when the workflow must preserve user-level authorization.
- Validate inbound webhook source, event type, table, operation, and payload structure.
Operational considerations for Supabase integrations
Capacity and pagination
Use explicit REST pagination, field selection, stable ordering, and indexed filters. For larger workloads, consider controlled PostgreSQL batching while respecting database capacity, transaction size, connection limits, and pooling behavior.
Retries and idempotency
Transient API, network, and database failures should use bounded retries with backoff. Persist event identifiers or deterministic business keys so webhook redelivery and workflow retries do not create duplicate records or external side effects.
Schema and event coverage
REST and GraphQL schemas derive from the PostgreSQL schema and permissions. Treat migrations as integration changes, validate expected fields and types, and do not assume Database Webhooks cover Auth, Storage, or every platform event.
Testing and monitoring
- Test elevated and end-user authorization paths separately.
- Validate webhook payloads and response behavior before enabling production delivery.
- Monitor API failures, database connections, workflow duration, file transfer status, and reconciliation results.
- Use bounded transaction scopes and avoid holding database connections across long-running workflow steps.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration across systems
Martini coordinates Supabase APIs, PostgreSQL, Storage, external applications, and file or messaging endpoints in one workflow rather than requiring separate point-to-point scripts.
Reusable integration logic
Workflows and APIs can centralize authentication, validation, mapping, business rules, checkpoints, retries, and error handling. This makes synchronization behavior easier to maintain as Supabase schemas and downstream contracts evolve.
Controlled enterprise access
Martini can expose a governed API façade and keep Supabase credentials in secure configuration. It can also preserve end-user authorization where required instead of forcing every process to use an elevated service credential.
Operational reliability
- Use scheduled reconciliation alongside event-driven Database Webhooks.
- Apply idempotent writes and durable processing state.
- Monitor failures and route invalid data for controlled handling.
- Reuse mappings and workflow patterns across applications and environments.
Frequently asked questions
Supabase can integrate through its PostgREST REST APIs, the pg_graphql GraphQL API when enabled, direct PostgreSQL connectivity, Storage APIs, and selective Database Webhooks for configured table events. Enterprise workflows can use these mechanisms to synchronize tables, process files, receive database changes, and coordinate calls to downstream applications.
Yes. Martini can consume Supabase REST and GraphQL APIs, receive Supabase Database Webhook callbacks through an exposed API, call Storage endpoints, and connect to Supabase PostgreSQL where network, SSL, and permissions allow. No native Martini Supabase connector is established in the supplied documentation.
No. A dedicated Supabase connector is not required. Martini can use Supabase's native REST, GraphQL, Storage, PostgreSQL, authentication, and Database Webhook mechanisms through workflows, APIs, mappings, and secure configuration.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Supabase. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Supabase, cloud or hosting infrastructure, database and storage usage, network transfer, or other third-party services.
REST is the primary general-purpose option for table and function operations. GraphQL is available when pg_graphql is enabled and the workload benefits from GraphQL queries or mutations. Direct PostgreSQL access suits controlled SQL, batch, reporting, or migration workloads, while Storage APIs handle files and Database Webhooks support selected table-event notifications.
Yes. Martini can receive Supabase Database Webhook requests for configured table inserts, updates, and deletes through an exposed API or webhook workflow. Supabase Realtime uses persistent WebSocket connections, and Database Webhooks should not be assumed to cover every Auth, Storage, or platform event.
Martini can map Supabase rows, GraphQL results, webhook payloads, and Storage metadata into canonical and target-specific models. Reliable synchronization should use stable keys, timestamps or identifiers for checkpoints, PostgreSQL upserts or equivalent target operations, and persisted event identifiers to make retries and repeated deliveries idempotent.
Yes. Martini can expose a controlled REST API that validates requests, applies business rules, and orchestrates calls to Supabase REST, GraphQL, Storage, or PostgreSQL interfaces. This can prevent direct exposure of elevated Supabase credentials and provide a stable contract for downstream applications.
Related Martini documentation
Workflows
Connect Supabase with Martini
Use Martini to integrate Supabase APIs, PostgreSQL, Storage, and selected Database Webhook events with the enterprise systems that depend on your application data.