Partnerships API
Set up and manage lead-sharing partnerships with other Goliath organizations through the Goliath developer API
About
A partnership links your organization to another Goliath organization so leads can be handed between you. Use these operations to find a prospective partner, send or answer an invitation, choose which of your users the partner sees, and end a partnership.
All operations go through the developer API gateway — one endpoint, called by
operationId. If you haven’t set up a key yet, start with the
Developer API Overview.
Every partnership is read from your side: partnerOrg is the other
organization, and its id is the partnerOrgId every partnership mutation
takes. direction says whose leads flow to whom:
direction |
Leads flow |
|---|---|
SEND_ONLY |
From you to the partner |
RECEIVE_ONLY |
From the partner to you |
BIDIRECTIONAL |
Both ways |
A partnership is PENDING until the invited organization accepts, then
ACTIVE, and TERMINATED once either side ends it.
Operations
Reading partnerships (READ scope)
| operationId | What it does |
|---|---|
listPartnerships |
Every partnership your organization has — ACTIVE, PENDING, and TERMINATED. awaitingCurrentOrgResponse is true when the partner invited you and you have not answered. permittedUserIds are your users the partner may see when sending leads (empty means all). |
listPendingPartnershipInvites |
Invitations other organizations sent you that still await your answer. Each row’s partnerOrg.id is the partnerOrgId for acceptPartnershipInvite or rejectPartnershipInvite. Invitations you sent appear in listPartnerships as PENDING instead. |
canShareWithPartners |
True when your organization has at least one ACTIVE partnership in a sending direction (SEND_ONLY or BIDIRECTIONAL from your side). Check it before promising that a lead can be handed to a partner. |
Managing partnerships (ADMIN scope)
| operationId | What it does |
|---|---|
lookupPartnerOrg |
Resolve a prospective partner by exactly one of an admin’s phoneNumber or email. Returns the matched admin and their organization; use the organization id as partnerOrgId. |
createPartnershipInvite |
Invite another organization: partnerOrgId and direction. Optional permittedUserIds limits which of your users the partner sees (empty means all); optional recipientUserIds picks which partner admins are notified (omit it to notify all). The partnership stays PENDING until accepted. |
cancelPartnershipInvite |
Withdraw an invitation your organization sent, before the partner accepts. |
acceptPartnershipInvite |
Accept an invitation another organization sent you; the partnership becomes ACTIVE. Optional permittedUserIds. |
rejectPartnershipInvite |
Decline an invitation another organization sent you. |
updatePartnershipPermittedUsers |
Replace which of your users a partner sees when it sends leads. Pass the full permittedUserIds list; an empty list means all users. |
terminatePartnership |
End an active partnership; either side may. All lead sharing with that organization stops. |
Example
Look up a prospective partner by an admin’s email, then invite them to a two-way partnership:
curl -X POST https://server.goliathdata.com/api/v1/call \
-H "Authorization: Bearer gsk_YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{ "operationId": "lookupPartnerOrg", "variables": { "email": "admin@example.com" } }'curl -X POST https://server.goliathdata.com/api/v1/call \
-H "Authorization: Bearer gsk_YOUR_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: invite-2026-10-28-1" \
-d '{ "operationId": "createPartnershipInvite", "variables": { "partnerOrgId": "PARTNER_ORG_ID", "direction": "BIDIRECTIONAL" } }'Full variable schemas, response shapes, and worked examples for every operation are available from the discovery endpoint.