Integration Logs are the audit trail for everything a form sends onward — Mailchimp, Notion, Slack, webhooks and the rest — recording the request that went out and the response that came back for every attempt.
Where: Tiger Forms → Logs.
What each entry shows
Every row ties one outbound attempt to the submission that triggered it:
- The submission the send belongs to.
- The integration that ran (provider and destination).
- The payload sent — the exact request body, with API keys, tokens and signatures redacted.
- The provider’s response and status, so you can confirm a lead reached your CRM or read the precise reason a webhook was rejected.
Retries
Because integrations retry failures on a backoff schedule, a single submission can produce several log rows for the same integration — one per attempt. Reading them in order shows the failure, the wait, and the eventual success (or the final give-up), which is exactly what you need when a provider was briefly unavailable.
Keeping logs tidy
Logs accumulate over time. Under Tiger Forms → Tools, the cleanup action removes integration logs older than 90 days so the table stays small and fast. Nothing about your submissions is affected — only the delivery records are pruned.
Troubleshooting
An integration “isn’t working.”
Check the log first. The provider’s recorded response almost always names the exact problem — a bad API key, a missing required field, or an unknown list/audience ID — which is faster than guessing.
I see the same send logged several times.
That is the retry ladder at work. The earlier rows are failed attempts; look at the most recent row for that integration to see the final outcome.
Secrets in the payload — is that safe to share?
Yes. Authorization headers, API keys, tokens and signatures are masked before the request is written to the log, so you can share a log entry for support without exposing credentials.