Skip to main content

​
Before you start

To build an integration with Slant, start by filling out the partner application form. 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. 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:
No request body is required. A successful request returns 201 Created:
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. 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: Treat every ID as an opaque string. For example, a client.created payload can contain:
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:
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.