> ## Documentation Index
> Fetch the complete documentation index at: https://docs.slant.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Partner integrations

> Create an OAuth app, connect Slant users, and receive webhooks for their books.

## Before you start

To build an integration with Slant, start by filling out the [partner application form](https://www.slant.app/partner-with-us). We'll review your application and create a partner demo account for you once approved.

Your partner demo account gives you access to **Settings → OAuth apps**, where you can create an app and start testing your integration. You'll also need a server that can store OAuth credentials securely.

Webhook subscriptions require a user's OAuth access token. Personal access tokens and MCP tools cannot create or remove these subscriptions.

## Create and connect your OAuth app

1. Open **Settings → OAuth apps** and select **Create app**.
2. Enter your app name and redirect URLs. Save the client secret when it is displayed; you cannot view it again.
3. Complete the OAuth authorization-code flow using your app's client ID, registered redirect URL, and the authorization and token URLs supplied for your Slant integration. Slant configures the app's OAuth scopes in Clerk. Validate the callback's `state`, use PKCE, and exchange the code on your server with your client credentials.
4. Use the resulting access token as `Authorization: Bearer <access_token>` when calling the [public API](/api-reference/overview). Call `GET /v1/me` to check the authenticated user and `GET /v1/books` to see their accessible books.

New apps start in **Sandbox**, where connections are restricted to your partner company. Contact Slant to enable production access for customer firms. Keep client secrets and refresh tokens on your server. Use **Rotate client secret** in the app's three-dot menu when you need a replacement secret.

### Connect users who belong to multiple companies

Each OAuth connection authorizes access to one company. When a user belongs to multiple companies, Clerk's authorization screen lets them choose which company to connect. The company currently selected in Slant is preselected, but they can choose another company before approving access.

To access data from multiple companies, repeat the OAuth authorization flow for each company and store each connection's access and refresh tokens separately. Use the token for the relevant company when making API requests. Changing companies in Slant does not change the company authorized by an existing token.

## Configure webhook delivery

1. In **Settings → OAuth apps**, open your app's three-dot menu and select **Webhooks**.
2. Select **Add Endpoint** in the embedded Svix portal and enter your HTTPS receiver URL. You can use **Svix Play** for a disposable test receiver.
3. Select the event types you want and create the endpoint. Leaving the event selection empty receives all event types.
4. Save the endpoint's signing secret securely for signature verification.

Slant creates one Svix application for your OAuth app the first time you open **Webhooks**. Reopening it reuses that application. Its endpoint configuration applies to all users subscribed through your app; opening the portal alone does not subscribe anyone.

Available event types are `client.created`, `client.updated`, `contact.created`, `contact.updated`, `prospect.created`, `prospect.updated`, `person.updated`, and `household.tag_added`. The portal's **Event Catalog** lists the available types, and **Logs** shows messages and delivery attempts.

## Subscribe a connected user

After the user authorizes your app, call:

```bash theme={null}
curl --request POST https://api.slant.app/v1/webhook_subscription \
  --header "Authorization: Bearer $SLANT_ACCESS_TOKEN"
```

No request body is required. A successful request returns `201 Created`:

```json theme={null}
{
  "id": "subscription_public_id",
  "user_id": "user_public_id",
  "created_at": "2026-10-15T12:00:00Z"
}
```

The subscription covers all books the user can currently access within the company authorized by the token. You cannot select individual books or subscribe another user by passing IDs. Repeated calls for the same app and user return the existing subscription. Access-token refresh does not create a new subscription.

For a user connected to multiple companies, call this endpoint separately with each company's OAuth token. Each company connection has its own subscription. You can use the same webhook endpoint for all of them; the payload's `company_id` identifies which company an event belongs to. Unsubscribing with one company's token leaves the other companies' subscriptions active.

Slant checks current user and app eligibility when submitting each event. Losing access to one book stops that book's events. An inactive user or disabled app receives no new events. Subscriptions have no inactivity timeout or periodic renewal requirement.

## Receive and verify events

Use the endpoint signing secret and the `svix-id`, `svix-timestamp`, and `svix-signature` headers to [verify the raw request body with a Svix library](https://docs.svix.com/receiving/verifying-payloads/how). Verify before processing; parsing and re-serializing JSON before verification changes the signed content.

Persist or enqueue accepted events, then return a successful `2xx` response promptly. Svix handles delivery retries. Make processing idempotent using `svix-id` so a retried delivery does not repeat your work. Do not assume exactly-once delivery.

Partner payloads add the following context to the event's resource fields:

| Field | Meaning |
| - | - |
| `subscription_id` | The app/user subscription that caused this delivery. |
| `user_id` | The subscribed Slant user. |
| `book_id` | The book containing the changed record. |
| `company_id` | The company that owns that book. |

Treat every ID as an opaque string. For example, a `client.created` payload can contain:

```json theme={null}
{
  "id": "client_public_id",
  "name": "Example household",
  "status": "active",
  "tier": null,
  "aum": null,
  "became_client_at": null,
  "type": "client",
  "subscription_id": "subscription_public_id",
  "user_id": "user_public_id",
  "book_id": "book_public_id",
  "company_id": "company_public_id"
}
```

If two subscribed users can access the same book, your app receives a separate copy for each subscription. Those copies have distinct message IDs. Decide whether to subscribe only one user per firm or handle overlapping subscriptions in your integration; deduplication by `svix-id` alone does not combine them.

## Disconnect and unsubscribe

Before discarding a user's OAuth credentials, call:

```bash theme={null}
curl --request DELETE https://api.slant.app/v1/webhook_subscription \
  --header "Authorization: Bearer $SLANT_ACCESS_TOKEN"
```

Success returns `204 No Content`, including when the subscription is already absent. This removes only the authenticated app/user subscription. It does not revoke OAuth API access, delete the app's endpoints, or affect other users. A later subscribe request creates a new subscription ID.

Disconnecting a connection through Slant's administrative controls also removes its app/user subscription. Deleting the OAuth app removes its subscriptions and schedules its remote Svix application for deletion.

Revoking OAuth access outside Slant does not automatically unsubscribe the user. Your disconnect flow must call unsubscribe while it still has a valid token. Messages already submitted to Svix may still arrive after unsubscribe or loss of access.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.