CaseWizard

Webhooks and OAuth clients

Configure HTTP callbacks and OAuth2 client-credentials applications for integrations.

Webhooks send signed HTTP POST requests when supported tenant events occur. OAuth Clients provide client-credentials applications with tokens for server-to-server access on behalf of the tenant.

Configure a webhook

Open Administration → Webhooks.
Register the receiver's endpoint URL and create or enter the signing secret.
Subscribe to only the events the integration needs.
Implement HMAC signature verification in the receiver.
Send a test event through your integration process and confirm that the receiver accepts the signed request.

Supported events

CaseWizard supports these webhook event types:

  • case.created
  • case.updated
  • invoice.created
  • invoice.updated
  • payment.created
  • payment.updated

Subscribe to the smallest useful set. Your receiver should identify the event type, validate the signature, and handle duplicate or delayed delivery safely according to your integration design.

Keep the webhook secret private. Verify the HMAC signature before processing request data, and use an HTTPS endpoint controlled by your integration.

Register an OAuth client

Open Administration → OAuth Clients.
Create a client with a descriptive name and the allowed scopes.
Copy the client ID and secret into secure deployment configuration.
Use the client credentials to obtain tokens from /v1/auth/token for server-to-server access on behalf of the tenant.

Choose scopes based on the application's actual work. Review them when the application changes, and remove or rotate credentials when the application is retired or its owner changes.

Choose between webhooks and OAuth clients

Use a webhook when CaseWizard needs to notify your system about a supported case, invoice, or payment event. Use an OAuth client when your system needs to authenticate to CaseWizard as a server-side application. An integration may use both, but configure each credential and permission set for its specific purpose.

Keep endpoint secrets, client secrets, and any resulting access tokens out of source control and user-facing code. Limit access to the administrators and deployment systems that need them.

API keys are another option for programmatic access. Review API keys when an integration does not require OAuth client credentials.

Review integrations

Document each webhook and OAuth client with its owner, purpose, scopes, endpoint, and review date. Revisit the configuration after staffing changes, vendor changes, or changes to the firm's document, billing, or case workflows. Review related activity in Audit logs when investigating a change or integration issue.

Next steps

API keys

Create scoped tokens for REST API access.

Audit logs

Review integration and administrative activity.

Developers

Review API and integration guidance.

Previous

API keys

Next

Feature requests

On this page