Developer overview
What you can integrate with Vipter today (signed webhooks, checkout URL parameters, the UTM script and this documentation in Markdown), what doesn't exist and where to start.
This section is for anyone connecting a Vipter store to their own system: an ERP, a CRM, an in-house member area or a reporting database. The pages go straight to the format, the numbers and the code. For the steps in the dashboard, each page points to the version written for store owners.
What exists today
| Feature | Direction | What it is for | Reference |
|---|---|---|---|
| Outgoing webhooks | Vipter → your server | A JSON POST, signed with HMAC SHA-256, for every sale, refund, subscription change, new customer or abandoned checkout. There are 20 event types, with automatic retries. | Event catalog, envelope, signature, retries |
| Checkout URL parameters | Your site → checkout | Build links that open with a pack, coupon, seller, language, currency, buyer details and campaign source already set. | URL parameters |
t.js script | Your sales page → checkout | Carry UTMs, click IDs, ad cookies and the seller code from your page to the checkout link. | t.js script |
| Documentation in Markdown | Docs → you or an AI | Every page of this help center exists in Markdown: add .md to the address. https://docs.vipter.com/llms.txt lists every page, in every language, with its Markdown link. | This page in Markdown: https://docs.vipter.com/en/developers/overview.md |
What doesn't exist
- Public REST API and API keys for store owners. You can't query orders, create customers, generate charges or change subscriptions through an API. Communication is one-way: Vipter notifies your system by webhook, and anything that needs an action is done in the dashboard.
- Managing endpoints through code. Webhook endpoints are created, turned on, turned off and removed only in the dashboard.
- Fetching past events. An endpoint receives the events created while it exists and is active. There is no way to request the history or resend events in bulk. The dashboard resends one delivery at a time, among the most recent ones. See Retries, disabling and resending.
- Events outside the catalog. Only the 20 types in the catalog go out by webhook. There is no event for a generated PIX (Brazil's instant payment), a pending order or a cart in progress.
Where to start
- Create an
https://endpoint in GeneralIntegrationsAutomationsWebhooks and store thewhsec_…secret, which is shown only once. The step-by-step guide with screenshots is in Receive events in your system. - On your server, read the raw request body and verify the signature before anything else.
- Answer with a 2xx code within 10 seconds and process the event afterwards, in a queue. A slow response counts as a failure and triggers retries.
- Store the
idof each event and ignore the ones already processed. Delivery is "at least once": the same event can arrive more than once. See idempotency. - Click Send test event in the dashboard and check under Recent deliveries that your system accepted the delivery.
One endpoint per purpose
Each endpoint has its own secret, its own list of events and its own delivery queue. A failure on one endpoint does not delay the others. If two systems receive events, create one endpoint for each.
What to do next
- See what comes in each event in the event catalog.
- Build checkout links with the URL parameters.
- Carry the source of your sales from your page to the checkout with the t.js script.
Contact the seller
For people who bought from a store that uses Vipter. Where to find the store's contact and why questions about the product, delivery and refunds go to the store.
Event catalog
The 20 event types Vipter sends by webhook, when each one fires and what comes in data.object, with a full example of an order, a subscription, a customer and an abandoned checkout.