Tally's API access depends on plan. Where the API is available, SleekView reads from it; where it isn't, the integration falls back to webhook ingestion (you point a Tally webhook at a SleekView endpoint and submissions arrive in near-real-time without polling). Both paths populate the same local cache, so the SleekView views work either way.

SleekView doesn't change how Tally is embedded (popup, embed snippet, redirect link). It runs in parallel: connect SleekView to the Tally workspace via API key (or webhook URL), pick which forms to sync, and submissions populate the local table. The embed continues to work whether or not SleekView is running.

Hidden fields are part of every submission payload Tally sends, so they pivot into columns automatically. Partial submissions are captured if Tally's partials feature is enabled for the form and the API or webhook surfaces them, SleekView shows partials as a separate state in the cache and a filter for triaging abandoned submissions.

Tally's submission API is read-mostly, so SleekView doesn't write back to Tally. Local fields (triage tags, processed flags, assignee) are inline-editable in WordPress, and those edits persist in the local cache. The original submission stays as Tally received it.

Webhook ingestion is near-real-time. API polling supports configurable intervals (5 minutes, 15 minutes, hourly, daily). Manual refresh from the SleekView toolbar forces an immediate pull when needed. For low-volume forms the daily sync is usually plenty; high-volume forms typically use webhook ingestion.

Yes, that's a primary reason hidden fields exist on embedded forms. If your embed passes the current WP user ID as a hidden field, SleekView surfaces it as a column and uses it to join to the WP users table. The result is a single view that shows Tally responses with the full WordPress user record alongside (last login, role, custom user meta).

Tally hosts file-upload responses on its own storage. SleekView surfaces the file URLs as columns; clicking opens the file in Tally's hosted location. SleekView doesn't re-host the files, since that would duplicate storage and complicate retention. URLs work as long as Tally retains the upload.

Payment-enabled Tally forms surface payment status, amount, and currency in the submission payload. Those become columns in SleekView like any other field. The actual payment processor (Stripe, etc.) remains the source of truth for refunds and chargebacks; SleekView shows what Tally captured at submission time.