--- title: Insy for developers description: Build on Insy — sell access to paid communities, Telegram groups and digital products with a REST API, outbound webhooks and Sign in with Insy. --- Insy is a platform for selling access. Creators use it to run paid communities, gate Telegram groups behind a subscription, and sell digital products. This site documents the three surfaces you can build against: a REST API you call with an API key, outbound webhooks you receive, and Sign in with Insy — an OAuth 2.0 flow that lets an Insy user grant your application access to their account. With these you can provision memberships from your own funnel, open a hosted checkout from your own landing page, react to payments and membership changes as they happen, and let people sign in to your product with their Insy account. Pick the integration surface that fits what you are building, then make your first call. Server-to-server calls authenticated with an API key: provision memberships, create checkout sessions, sign people up for drops. Five signed event types delivered to your endpoint when memberships, payments and digital product purchases change. OAuth 2.0 authorization code flow, plus a drop-in login widget that needs one script tag. ## What you will need Every credential below is self-serve. They all live under **Account → Developer** in the Insy app, and nothing here waits on a human. - **An API key**, if you are calling the REST API. Create one at [Account → Developer → API keys](https://insy.io/account/developer/api-keys), choosing the permissions it needs — reading memberships, writing memberships, creating checkout sessions, or drop notification signups. The key is bound to a user account, not to a single community: it can act on every community where that account holds an active OWNER or ADMIN membership. You see the key once, in plaintext, and never again. See [Authentication](/developers/api/authentication). - **An OAuth client**, if you are using Sign in with Insy. Register one at [Account → Developer → OAuth clients](https://insy.io/account/developer/oauth-clients) with your application name, redirect URIs, the scopes you want (`memberships.read`, `products.read`), optionally a logo, and — if you are embedding the login widget in a browser — the web origins it will run on. You get a `client_id`, and a `client_secret` if your client is confidential. See [Sign in with Insy](/developers/oauth). - **A webhook endpoint**, if you want to receive events. Webhooks are registered from inside the Insy app by the account that owns the community or the product. See [Webhooks](/developers/webhooks). > **One thing still goes through support** > > `MEMBERSHIP_PROVISION` — the permission that mints paid access without a payment — is not > offered on the self-serve form and is granted only to vetted partners. Email > [support@insy.io](mailto:support@insy.io) for that one, saying what you are building and which > community it belongs to. Everything else you can issue yourself. ## Base URL Every REST endpoint in these docs is relative to a single host. There is no version prefix in the path. ```bash title="API base URL" https://api.insy.io ``` The OAuth endpoints themselves — `authorize`, `token`, `revoke` and the resource endpoints — are served from `api.insy.io` alongside the rest of the API. What lives on the storefront host instead is the user-facing storefront, the consent screen the user sees during authorization, and the `widget.js` login script: ```bash title="Storefront" https://insy.io ``` > **There is no sandbox** > > Insy has one environment. Every call you make from these docs is live: real memberships, real > charges, real Telegram invites. Test against a community you control, and use small amounts.