Start with one app.
Make the signals useful.
A project gives your events and monitors a home. Connect the parts you care about first; add more once the first alert makes sense.
Create a project for the app.
Give it a name you will recognize on your phone. Keep test and live data separate. An experiment, a production app and a scheduled service can each have their own project.
Indie does not charge per project. The plan’s check, heartbeat and incoming-event allowances apply across the workspace.
Add a check that tells you something.
For a web app, start with an HTTP check on a meaningful page or API endpoint. Choose what a successful response looks like. Add certificate or DNS checks when those are useful to your setup.
For a background job, use a heartbeat with the expected interval and an appropriate grace period. Send the heartbeat after successful work, not before it starts.
Choose how sales and events arrive.
Stripe webhook: configure an event destination in Stripe and save its signing secret in the project’s server-backed setup. That secret lets Indie verify delivery; it is not your full Stripe account key.
Connect Stripe: approve scoped access in Stripe, assign charges to projects, and optionally import 90 days of history. This flow is implemented locally and still being tested before public availability. Imported history stays silent.
Events API: have your app’s server send purchases, refunds, customer-message events or system alerts. This works for your own business logic and other payment flows when you implement the integration.
A useful brief for
your coding assistant.
You can ask your coding assistant to wire the Events API into your app. Give it the project-specific instructions from Indie along with this brief.
Add a server-side integration with Indie. Read the project's Events API instructions first. Store its key in a server-only environment variable. Never expose it in frontend code, logs or a repository. Send a sale only after payment is confirmed. Include the amount in minor currency units, currency, transaction ID and the correct project. Use a stable, unique Idempotency-Key so retries do not duplicate sales. Send refunds when the provider confirms them. For a critical background job, add the Indie heartbeat configured for that job. Report failure explicitly and do not send success before the work finishes. Handle network errors and non-2xx responses with bounded retries and visible logs that exclude secrets. Verify one sample event and notification before enabling real events.
This is an implementation brief, not an automatic connection. Review the resulting code and test it before using real events.
Send a test. Open it on your phone.
Enable iPhone notifications, check sounds and Focus settings, and send a clearly labelled test event. Tap it and confirm that it opens the intended project or monitor.
For a monitor, test both failure and recovery. For a purchase, retry the same event and confirm it is not counted twice. A little verification now makes later alerts much easier to trust.
Keep the provider tools nearby.
Indie gives you the event and its context. Keep your logs, deployment controls and payment-provider records for deeper investigation. You should be able to trace an alert back to the system that sent it.
Read about data and accessOne useful connection
is a good place to start.
Start with your first project. Add a useful check and see your app’s activity in one place.
Start free trialSee launch pricing