API Tokens, Webhooks, and Account Controls

Personal access tokens

Personal access tokens exist for users who want to use the app programmatically instead of only through the browser.

From an end-user standpoint, a PAT is the account-approved key that lets your own tools or scripts act on the app's API according to the scopes you choose.

Webhooks

Webhooks let GetPaidX notify your external system when subscribed events happen.

Use them when you want your own system to react automatically instead of polling for changes.

The practical questions to answer before enabling one are:

• which events you care about,
• where the webhook should send data,
• whether the receiving endpoint is ready to verify signatures and handle retries.

Notifications and usage

Notification settings control how much of the app's activity reaches you through in-app and email channels.

Usage surfaces are where you monitor platform usage, AI-credit or usage-related status, and limits that affect how your account can use the system.

These pages are about account control and clarity, not about punishment or hidden restrictions.

Custom domains

Custom domains let eligible users map a branded hostname to their public app presence.

This feature matters when you want the product experience to feel native to your own brand instead of living only on the default GetPaidX host.

Related programmatic docs

The browser settings pages are the end-user setup layer. The programmatic API document explains the request-level API behavior once those settings are in place.

Most common account jobs

This page is the right starting point when you want to:

• create a PAT for your own scripts or tools,
• connect a webhook endpoint for account-level events,
• understand where notifications and usage controls fit around automation,
• decide whether branded-host setup belongs in your current account workflow.