How to integrate Unify with Supabase
To integrate Unify with Supabase, POST prospect JSON from a Play to an Edge Function you deploy. The function verifies the caller and writes validated fields to your chosen Postgres table. Keep request authentication, database access, and the rules for updating an existing prospect explicit.[1][3][5]
- Connection
- Custom webhook
- Developer platforms
- Tool
- Supabase
- Edge Function
- Data flow
- Unify → Edge Function → Supabase Postgres
- JSON payload
At a glance
- Separate webhook authentication from database authorization
- Define the allowed write before connecting the Play
- Inspect the saved record and repeat behavior
When this workflow makes sense
Start with the decision your team needs to make, then choose the connection that supports it.
A prospect record can be useful to an internal application before it is ready for a sales action. For example, a team may want a review queue that combines incoming facts with a human decision. Decide which fields represent Unify data and which belong to the reviewer. A later handoff should not silently erase the work already done by a person.
A good fit when
Teams building a prospect review or operations interface on Supabase and able to maintain an Edge Function and its access rules.
Reconsider the plan when
If no one owns the table schema, database permissions, or repeat behavior, define those responsibilities before connecting live Play traffic.
Design the handoff
Use this framework to agree on the input, the next action, and who owns the result.
Suggested workflow design, based on the documented capabilities below.
| Stage | Decision to make |
|---|---|
| Record | Choose the destination table and the person or company identity it represents. |
| Access | Authenticate the incoming request before granting it a narrowly defined write. |
| Update | Keep prospect facts separate from review status and human notes. |
| Validation | Inspect the saved row, invalid requests, and the effect of a repeated sample. |
Explore the scenarios
Choose the situation that fits your team and work through the proposed plan.
Open a scenario to explore its plan. Checklists track your selections in this page only.
Populate an application review queue
A prospect needs human qualification in a Supabase-backed interface.
Separate received facts from reviewer judgment so the next handoff does not erase an existing decision.
- Define prospect columns and separate review fields
- Implement an authenticated Edge Function with a limited write
- Inspect the fictional row from the intended reviewer’s interface
Preserve a decision on repeated intake
The same prospect can arrive while the reviewer is already working on it.
Choose the identity and allowed update fields before enabling repeats. A contact refresh should not reset a review by accident.
- Define the uniqueness rule for the record
- Save a sample and add a reviewer note
- Send the sample again and inspect the stored facts and note
Illustrative workflow, not a preconfigured automation. Complete these checks in your own account.
Define success before launch
Inspect the data and the intended outcome separately. Connection status is only the first check.
Expected, not tested
An authenticated request creates or updates the intended prospect record, while invalid requests leave the table unchanged.
Inspect the stored values, intended access behavior, and function logs. A 2xx response without a checked write result is not evidence that the row was saved.
Documentation-based reference. This workflow has not been tested end to end. Use a record or event you control before enabling live activity.
Questions answered
Common decisions when connecting Unify and Supabase.
How does Unify send data to Supabase?
A Play posts JSON to your deployed Edge Function. Your function validates the request and performs the database operation you implement.[3]
Does disabling verify_jwt make the webhook secure?
No. Disabling the gateway JWT check lets requests reach the handler. The proposed custom-header design must authenticate the caller inside that handler before any privileged action.[4]
Should I put a Supabase service credential in the payload?
Keep database credentials in the function environment. Use a separate receiver secret for the proposed Unify request so the prospect payload contains data rather than database credentials.[6]
Will Row Level Security always protect this write?
It depends on the client and role used in the function. An administrative client can bypass Row Level Security. Deliberately limit what the endpoint is allowed to write.[5]
Will a Supabase database webhook receive the Unify event?
This design receives HTTP through an Edge Function. Supabase Database Webhooks send requests in response to database changes; they are a different direction of integration.[8]
Limits & decisions
Check these boundaries before designing a live workflow around the connection.
- Requires a deployed function and application-specific database schema
- The custom secret check is code you must implement and test
- Authentication, authorization, and record uniqueness solve different problems
- Database changes do not automatically flow back into Unify
- No live Supabase function or write has been tested
What the connection supports
Understand the connection, the data involved, and the behavior that matters for a Unify + Supabase workflow.
POST / JSON, then an explicit database write
| Decision | What to know |
|---|---|
| Receiver | An Edge Function handles incoming HTTP requests[3] |
| Gateway authentication | verify_jwt and handler-level authentication are separate controls[4] |
| Database access | Edge Functions can connect to Supabase Postgres through a client[5] |
| Credentials | Function secrets make server-side configuration available to the handler[6] |
| Diagnosis | Function logs and invocation details help locate failures[7] |
Technical setup reference
References and requirements for the Supabase connection.
Connection requirements and setup checklist
Before connecting
- A Unify Play with a Webhook action
- A Supabase project with permission to deploy Edge Functions
- A destination table, an agreed record identity, and a developer responsible for database access
- A separate secret for this receiver, kept in function secrets and Unify authentication settings
Define the application record
Choose the table and the fields this handoff may write. For a review queue, keep received prospect facts separate from reviewer notes and status. Decide how an existing record should be matched before choosing insert or update behavior.[5]
Create an authenticated function
Deploy an Edge Function named unify-webhook. For the proposed custom-header method, configure verify_jwt = false for that function and implement X-Unify-Webhook-Key validation in the handler. Missing or wrong secrets must fail before database access. This example does not assume Unify provides a provider-specific webhook signature.[3][4]
Keep database credentials on the server
Store the receiver secret and any privileged database credentials in function secrets. Use the database client with access appropriate to the operation. Administrative access can bypass Row Level Security, so enforce the permitted destination and fields in code.[5][6]
Request configuration
- Method
POST- URL pattern
https://YOUR_PROJECT_REF.supabase.co/functions/v1/unify-webhook- Headers
Content-Type: application/jsonX-Unify-Webhook-Key: YOUR_WEBHOOK_SECRET- Authentication
- Suggested custom authentication: implement a check for X-Unify-Webhook-Key in your receiver and store the expected value as a server-side secret. In Unify, choose API Key (Header), use that header name, and enter the matching value. The header name is chosen for this example; the platform does not validate it automatically. For this custom-header design, set verify_jwt = false only for the receiving function and verify the secret in its handler before accessing data. Disabling the JWT gateway check alone does not authenticate a webhook.
Choose JSON as the body format. Unify sets Content-Type automatically. The receiver must respond within Unify’s 8-second timeout; request responses are not passed to later Play steps.[2]
Replace URL placeholders with the actual receiver URL from your account or deployed application. These example URLs are not working endpoints.
Example handoff payload
Start with a fictional prospect. Validate the resolved values before using a real record.
Inspect the sample payload and field mapping
{
"event": "prospect_handoff",
"prospect_name": "Alex Morgan",
"prospect_email": "alex@example.com",
"company_name": "Example Company",
"company_domain": "example.com"
}Fictional data. Replace sample values before using a real Play.
The keys are an example handoff format, not required Unify field names. Use the field mapping to distinguish record data from fixed settings. Select available fields in your Play and inspect Expand preview; do not replace configuration values with prospect data.[2]
| Payload field | Value to send |
|---|---|
event | A fixed label you choose for this workflow |
prospect_name | Use {{ person.first_name }} and {{ person.last_name }} for the prospect name |
prospect_email | Use {{ person.email }}; decide how to handle missing values |
company_name | Use {{ company.name }} |
company_domain | Use {{ company.domain }} |
Use an explicit mapping from the sample prospect properties to your application columns. Choose a unique identity at the database level when duplicates must be prevented; a read-before-insert check alone can race with another request.
Troubleshooting
Start with the stage where the expected data or action stops appearing.
The function returns 401 before my code runs
Check the function-specific verify_jwt setting. A custom API key header is not a Supabase user JWT. If disabling the gateway check for this design, first make sure the handler enforces its own authentication.[4]
The request arrives but the row is missing
Inspect the returned database error, column types, and the credentials used by the function. Review Row Level Security and permissions for that role instead of assuming webhook receipt grants write access.[5][7]
An update overwrites review work
Limit writable columns to incoming facts. Preserve reviewer notes and status unless changing them is an explicit part of the application contract. Inspect the update result with a repeated fictional record.[5]
Sources & review
Official documentation reviewed on September 15, 2026.
Technical claims link to primary documentation from Unify and the destination tool. Scenarios, field choices, and recovery plans are editorial implementation examples. Documentation review is separate from execution testing.
Documentation reviewed; end-to-end execution not tested. No named technical reviewer has signed off on these articles yet.
Content updated: . Report a correction to Unify with the tool name, source URL, and behavior you observed.
Keep exploring
