Data and storage

What Koil stores, what it only passes through, and for how long.

Koil stores what it needs to run your integration, and passes provider content through, keeping none of it beyond 24 hours.

What Koil stores

  • Publish request ledger — each pub_… entry's status, provider references, schedule, groupId, clientItemId, and timestamps.
  • Idempotency records — the operation, key, a hash of the request, and the result's ids. Kept for 24 hours.
  • Collection state — the cursors, watermarks, and rate-limit counters needed to collect events, kept while the Connected Profile and its content type remain active.
  • Media — med_… objects you upload or have Koil fetch, until you delete them. The file itself is kept only long enough to prepare publishes: a mediaId is publishable for 24 hours after creation, and each publish keeps its own prepared copy until it finishes.
  • Provider content waiting to become events — each webhook delivery a provider sends Koil, held until its events are published, then deleted. One that can't be processed is kept so it can be investigated, and deleted no later than 24 hours after it arrived. This is what lets delivery survive an outage on either side.
  • Your configuration — Auth Integrations (the OAuth client secret is write-only: no read returns it), Connections and their provider credentials, Connected Profiles, and Event Destinations.

Credentials

Provider credentials are kept only while something can still use them, and deleted with everything that depends on them:

  • Deleting a Connection deletes its credential, the credentials Koil derived from it (such as a Facebook Page token), and its Connected Profiles.
  • Deleting an Auth Integration deletes your app's client secret and any credential still stored under it. It is refused while a Connection you can see still uses it.
  • Deleting your Organization deletes every Connected Profile, Connection, and Auth Integration it had.
  • An end user revoking access makes the credential fail its next refresh, which Koil reports as connection.refresh_failed. A Connection whose refresh is still failing six days later is deleted, well inside the seven days YouTube allows after a revocation. Re-authorizing the Connection, or a later successful refresh, keeps it.

A revocation's deletions emit connected_profile.deleted and connection.deleted, as deleting through the API does.

What Koil does not store

Provider content observed through a Connected Profile — posts, comments, messages, mentions, and moderation outcomes — is delivered as events and discarded; a webhook delivery that carried it is deleted once its events are published, and kept no longer than 24 hours in any case. Content reads go to the provider each time. If your product needs history, persist it from the events you receive; a backfill request can re-deliver what is still on the provider.

A publish's own payload is held only while the publish runs and for two days after it ends, in workflow state encrypted at rest, and is never copied into Koil's database.

On this page