Guide

No.

The entire integration is a single HTTP POST request.

There is no SDK to install, no npm package, no CocoaPod, no Gradle dependency.

If your app can send an HTTP request (and every language and framework can), you can use Signalshoot.

The Setup Guide provides copy-paste code snippets for React Native (JavaScript/TypeScript), Swift (URLSession), and Kotlin (OkHttp).

You can also point an AI coding assistant (Claude, Cursor, Copilot) at the OpenAPI spec and it will generate the integration code for your specific platform.

New feedback submissions are rejected with a 429 status code and an error message stating your monthly limit has been reached.

Your existing feedback data is not affected — you can still read, triage, reply, and export everything already in your inbox.

The count resets on the first day of each calendar month.

Threaded follow-ups (sent with parent_id) do not count toward the limit, so ongoing conversations continue to work.

You can upgrade your plan from the Settings page at any time, and the new limit takes effect immediately.

Yes.

Go to Settings and click "Manage Billing" to open the Stripe billing portal, or use the plan selection in the Settings page.

A downgrade takes effect at the end of your current billing period — you keep Pro features until then.

After the downgrade, your feedback limit drops to 200/month, your app limit drops to 1, and the 6-month data retention window applies.

Feedback older than 6 months will be scheduled for deletion.

If you have more than 1 app, you will need to choose which one to keep.

Yes.

If Signalshoot is ever discontinued, you will receive an email notification at least 90 days before the shutdown date.

During that period, the service continues to operate normally and full data export (CSV and JSON) is available to all users regardless of plan.

After the shutdown date, the dashboard remains in read-only mode for an additional 30 days for final exports.

This commitment is written into the Terms of Service as a binding obligation, not just a goodwill promise.

Free plan supports 1 app.

Pro supports up to 5 apps.

Infinite supports unlimited apps.

Each app gets its own unique App ID, its own pair of API keys (live and test), and its own isolated data store.

Feedback from App A never appears in App B's inbox — the database queries are scoped by app ID.

You can switch between apps in the dashboard.

If you have a production app and a side project, Pro lets you manage both from the same Signalshoot account without any data mixing.

Not yet, but it is planned.

The Infinite plan will support up to 3 team members in a future update.

Each member will sign in with their own GitHub or Google account and share access to the same apps, inbox, and action items.

Currently, all plans are single-user — one developer account, one login.

If you need team access right now, the workaround is sharing the dashboard session, but we recommend waiting for the proper multi-user support.

We accept Visa, Mastercard, American Express, and JCB via Stripe.

Both USD and JPY billing are supported — Stripe handles currency conversion automatically.

Billing is monthly with no annual commitment.

You can cancel from the Stripe billing portal at any time, and the cancellation takes effect at the end of the current billing period.

No refunds for partial months.

Stripe handles all payment processing; Signalshoot does not store your card details.

Only the initial feedback submission (a POST request without parent_id) counts toward your monthly limit.

Follow-up messages in the same thread — sent with parent_id pointing to the original feedback — are stored as replies and do not increment the counter.

Developer replies written from the dashboard also do not count.

So one conversation thread between you and a user costs exactly one feedback count, regardless of how many messages go back and forth.

Test-key submissions (fb_test_...) are also excluded from the count.

Signalshoot validates the structure and size of your requests: type must be a non-empty string under 50 characters, message must be non-empty and under 5,000 characters, channel must be under 100 characters if provided, and the body must be valid JSON.

However, the API does not validate the semantic meaning of these values.

If you send type: "banana", it will be accepted and "banana" will appear as a filter option in your dashboard.

The same applies to channel and metadata — the API stores whatever you send, and the dashboard displays it as-is.

This flexibility is intentional: you define your own taxonomy.

The tradeoff is that typos in your code (e.g. "bugg" instead of "bug") will create new filter categories silently.

Go to Settings and regenerate the key immediately.

The old key is invalidated the moment you regenerate — any request using it will receive a 401 error.

A leaked API key has limited scope: it can submit new feedback to your inbox and retrieve feedback messages and replies for a specific user_id via the replies endpoint.

It cannot access the dashboard, cannot modify or delete existing feedback, cannot read feedback without a user_id, and cannot perform any administrative action.

The risk depends on your user_id format: if you use sequential integers (1, 2, 3), someone could enumerate user IDs and read their feedback.

If you use UUIDs or random strings, the risk is minimal.

For web apps, the best practice is to keep the API key on your server side so it never appears in browser source code.